开发者可能低估了容器部署的复杂性

在上一篇文章中，我认为，在谈论 Kubernetes 时，炒作成分可能已经大于实际采用。对该文章的回应不一而足，从有关容器的基本问题，到非常坚定的观点：许多人已经在运行多集群、多云容器化的基础设施。关于后一种观点，根据我的经验，小型的、更敏捷的公司往往低估了大型企业对变革的缓慢反应背后的复杂性（在拆解大集团的缓慢动作方面， Ian Miell 在《为什么大集团行动这么慢？》一文中做了绝佳解读）。因此，本文将尝试解决以下三件事：

一些非技术人员可能还想了解容器是什么，因此本文尝试简化相关基本定义
很多公司已经成功采用容器技术，就此提出这些公司的共有属性是什么
解释为什么迁移到容器只是面临的 IT 问题的冰山一角

问题：应用在 VMware 的容器中运行，它是云原生的吗？

很遗憾地说，不一定。我们要记住，容器只是一个可以在基础架构上运行的软件包，并且（至少）有两种类型的容器。

自从 LXC（2008）或者可以说是之前的 Solaris Zones 时代以来，系统容器就已经存在很长时间。简单来说，这些就是行为类似于虚拟机的小型、高效的单元。它们可以支持多个可执行应用程序、提供隔离功能，同时还有系统管理员可以安全使用的其他功能，例如易管理性。如果希望在不彻底改变 IT 实践的情况下实现容器化，这对传统应用程序是非常理想的，而且好处很简单：与虚拟机相比，每台服务器的应用程序密度提高了 10 倍以上。

应用程序容器只有一个要执行的应用程序。这是 Docker 图像格式（与 Docker Engine，Docker Swarm 或 Docker Inc. 不同）和 OCI 的世界，也是大多数人在提到“容器”一词时所指的世界。从 IT 角度来看，这带来的好处是，运行微服务应用程序的应用程序容器可以实现云原生的全部优势：高交付速度、几乎无限的可扩展性和更高的弹性。这些戏剧性的成果需要重大的文化和技术转变，稍后会详细提及。

容器只是外表，更广泛地讲，只会做被告知要做的事情；微服务是编写软件应用程序的架构方法；云原生是一种提供应用程序的方法。回答前面的问题：抛弃现有资源、忽略商业产出以追求理想，可能不是好的实践，所以，如果有一个 VMware 环境可用，那对现状而言已经足够云原生了（从这个角度来看，VMware 收购 Heptio 对于未来的用例而言是很有趣的）。最重要的是，想通过最简单的项目（也就是容器）来解决前述一大串问题的想法是常见的错误。

IT 中没有雷神之锤

我最近和一家英国大型金融服务公司的云服务部门负责人见面，他告诉我，公司的前任 CIO 因为未能实现“直接无服务”战略而不得不离职。“直接无服务”战略即直接越过云和容器的革命技术，从而在公司运转良好的私有数据中心直接运行无服务技术。 CIO 不得不离开并不意外：在任何工作中，都需要使用合适的工具来完成合适的工作，特别是当这些工作很复杂的时候。在云中，这意味着，在大多数情况下，用户可能会在私有服务器、私有云或公有云的任意组合上综合使用裸机、虚拟机、容器和无服务器。

毫无疑问，据我所知，成功的 IT 转型过程的第一步是：不要过度简化本就十分庞杂的 IT 革命或进化（®evolution）。相反，从整体上理解它，并根据业务成果和目标进行判断。能努力做到这一点已经很好，但并非所有公司都拥有成为云原生纯粹主义者的资源。即使不完全实现云原生，只是采取较小的步骤，也有明显的好处，例如允许更多时间去分析技术的影响，或实现更好的风险管理。（来自容器公司 Cloud 66 的这篇文章很好地描述了将单个 APP 迁移到容器的短期效率和长期洞察。）

已知和未知问题

但最终，如果容器只是容纳了更多的单个应用程序，用户就不会对容器革命感到如此兴奋了。一个在容器中运行的微服务应用程序，是在多个基板上编排的，而这一切都基于云原生原则 – 后者才是值得奋斗的东西。大多数人想要的是一个可以快速又可靠地扩展、运行资源少、能够快速适应客户和竞争动态并可以自我修复的应用程序。

再次重申，容器只是其中的一部分而已。考虑一下技术方面的挑战：编排如何操作？而网络又当如何？状态服务又当如何？云原生管道工具呢？

更重要的是文化方面的挑战：在推行开发实践时，需要改变什么东西？如何才能找到并留住合适的人才？如何重新培养年长的成员、在新人和老人之间架起桥梁？风险平衡又将如何变化？

开源已经融入战略

事实证明，云和开源的兴起已经相互联系起来，这也带来了一些有趣的现象，正如我在之前的文章中探讨的那样。在容器中，这种协同作用似乎比以往更加剧烈。 Kubernetes 和许多相关的开源项目，包括云原生计算基金会（CNCF），背后的主宰都是 Linux 基金会的一部分。CNCF 基金会章程明确了自身意图：旨在促进和维持一种开源的、厂商中立的项目的生态系统。因此，自 2014 年成立以来，通过大量开源项目的交叉混合， CNCF 基金会在管理复杂的云原生堆栈方面变得越来越轻车熟路（参见基金会年度报告中的一些有趣数据）。简单来说，使用容器本地化方法的次数越多，用到的开源项目也就越多。

另一方面，开源软件包构成了大量免费和专有应用程序 – 虽然整个应用程序可能是专有的，但团队实际编写的内容占比可能非常低。正如开源安全状态报告所示，开源项目的使用与数字化变革是紧密结合的，因此对业务越来越关键；但是，只有 17％的维护人员将安全专业知识排在高优先级，这意味着很多这些软件包都存在运维风险。

另一个方面是社区：使用更多的开源使得组织成为社区的利益相关者，因此这些组织应该与相关社区保持联系，以了解可以如何做出贡献、如何参与到项目路线图中并尽可能快地响应安全警报问题。