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

在上一篇文章中，我认为，在谈论 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％ 的维护人员将安全专业知识排在高优先级，这意味着很多这些软件包都存在运维风险。

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

结语

总结一下，关于加入容器浪潮的“简单”决定将固有并明显地增加组织从开源软件中的获益能力和曝光能力。该软件可能会也可能不会得到大型赞助商的支持，可能会在很大程度上由志愿者维护，并且可能会有一个充满活力的社区 - 所有这些人都需要依赖这些项目的用户参与。

换句话说，容器是数字化转型的关键部分，但只是其中一部分。数字化转型的一部分问题将会在毫无预期的情况下出现在软件交付系统中，如果与开源的开放性、成熟性和责任正确组合的话，整个数字化转型可以为应用程序提供优质的东西。

原文链接：https://www.forbes.com/sites/udinachmany/2019/02/11/these-are-not-the-containers-youre-looking-for/#1a6b31083a89