容器厌倦了被类型化

感恩节和……火鸡。 圣诞节和……树。 容器和......微服务。

如果您想到的第一个词与我的预期相符，那么您就已成为当今技术市场过度联想的牺牲品。 人们倾向于在任何关注其中一个的讨论中立即提到微服务和容器。 部分原因是微服务（一种将应用分解为集中的、敏捷的服务的架构方法）非常符合基于容器的部署模型的敏捷性。 但我们不要忘记，容器本身就是一种技术。 它们早在微服务成为人们眼中架构闪耀的亮点之前就已经存在，并且它们并不局限于对基于微服务的应用程序部署有益。

请考虑一下《2016 年企业发展趋势》中的这一信息，这是一项对 2100 名 JVM 开发人员的调查， Lightbend （自称是世界领先的 Reactive应用开发平台的骄傲提供商）从中得出了许多有关云、容器和微服务的见解。 有趣的是，虽然大多数人 (59%) 正在寻求将全新的应用容器化，但 41% 的人却将“现有应用”作为容器化的目标。

这根本不是什么异常。 快速跳转到Mesosphere在2016 年 8 月对 500 名 Mesos 用户进行的调查发现，51％ 的用户在 Mesos 上运行单片和遗留应用。 也许正如预期的那样，85％ 正在运行微服务架构。

容器显然不仅适用于新应用程序，而且还可以被用作一种手段，使传统应用程序和单片应用能够享受容器的诸多好处，如可移植性、快速扩展以及更好地适应 DevOps 驱动的操作。 毕竟，我们被承诺实现无摩擦的可移植性，但由于每个公共云提供商都采用不同的映像格式进行标准化，因此我们得到的是漫长的重新映像时间。 维护多个黄金映像（每个环境每个小分支每个主要分支一个..好吧，你明白了）成为了一场操作噩梦。 容器，比如蜜獾，并不关心。 它们会从一个操作系统滑动到另一个操作系统、从一个虚拟机到虚拟机、从一个云滑动到另一个云。 这是迄今为止提出的最佳方法之一，可以在眨眼间（对于那些一直在关注的人来说，大约是 400 毫秒）实现基于成本的无缝云迁移。

不过，我们不要将容器定型为一种“云”技术。 虽然它确实实现了许多长期吹捧但很少实现的云提供商之间的可移植性，但它并不局限于云或甚至类似云的环境。 Sumo Logic 最近的报告指出，容器确实在“云端”使用，其检查的应用程序中 15% 在生产中使用了 Docker。 但这并不意味着容器没有在其他地方使用，例如在本地。 事实上，前述 Mesosphere 报告指出，近一半 (45%) 的用户“仅使用本地部署”，而大多数用户则分为“混合部署”和“仅使用云部署”。 有趣的是，研究还发现“规模较大的公司（拥有 500 名或更多员工的公司）更有可能在现场运营。”

容器是一个有趣的部署选项，当得到容器编排解决方案（如 Docker、Docker swarm、Mesos 和 Marathon、Kubernetes 等）的支持时，它可以提供一个非常灵活的环境，可以在其中自动部署和扩展应用。 它是一个微云，或者至少是类似云的环境，可以部署在公共云、私有云中，或者根本不涉及任何“云”。 容器可用于部署和扩展单体应用、现代应用、基于微服务的应用和 API。 它们具有高度的灵活性，因为它们的重点是规范操作系统层，以使应用程序不与环境紧密耦合。

简而言之，容器是一个抽象层，它使应用程序成为蜜獾并且“不关心”较低级别的细节。 当由容器编排解决方案监控和管理时，该抽象可以实现自动扩大和缩小、扩大和缩小，从而在整个应用基础设施中提高资源效率。

虽然容器、微服务和云可能是最好的朋友，但它们都是可以独立存在的独立实体。 每种方式提供的优势都是互补的，有时我敢说，还可以与其他方式产生协同作用。 但是，我们不要将容器类型化为“仅”适用于微服务和“仅”适用于云的非常狭隘的模式。

容器已经厌倦了被类型化。 让他们尝试您的架构中的各种角色，您可能会发现他们有能力在每个角色中扮演主导角色。