Kubernetes 的魔力在于企业标准化，而不是应用程序的可移植性

笔者：Kubernetes 抽象了资源和工作负载的操作模式，统一了工具集，实现人机接口的标准化。正如类 Docker 工具提供了应用运行时的操作模式；Spring Framework 提供了 Java 应用的开发模式。

Kubernetes 是关于跨云的技能、工具和实践的可移植性。不是工作负载的可移植性。 -- Bilgin Lbryam @bibryam

本文翻译自 Kubernetes magic is in enterprise standardization, not app portability

Kubernetes 不会神奇地使你的应用程序具有可移植性，但它可能会给你带来更好的东西。

云为企业提供了看似无限的选择。然而，根据 Canonical-sponsored 的一项调查，这并不是大多数企业采用 Kubernetes 等云友好技术的原因。相反，Kubernetes 的主要目标是标准化——外观和操作与其他人一样。

可移植性不是目标

我之前已经讨论过这个问题，参考了 Gartner 关于 Kubernetes 和可移植性的指南。许多人认为 Kubernetes（和容器）可以让他们在云之间轻松移植，但事实证明并不是这样的。正如 Gartner 分析师 Marco Meinardi 所写，当被问及公司是否应该采用“Kubernetes 使他们的应用程序可移植......答案是：不。” 再说一次？

调查显示，[在云提供商之间移动应用程序] 的可能性实际上非常低。一旦部署在供应商中，应用程序往往会留在那里。这是因为数据湖难以移植且成本高昂，因此最终成为迁移的重心。

因此 Kubernetes 通常不会被公司接受，以增强应用程序的可移植性；相反，谈论人员可移植性或换言之，技能可移植性更接近事实。Weaveworks 首席执行官亚历克西斯·理查森（Alexis Richardson）将这个主题打回家：

重点是“技能可移植性”，因为使用标准操作模型和工具链。大型组织希望开发人员使用标准的工作方式，因为这可以降低培训成本，并消除员工在不同项目之间转移的障碍。如果你的“平台”（或多个平台）基于相同的核心云原生工具集，那么它也可以更轻松、更便宜地应用策略。

这让我们回到规范调查。

Samesies

当被问及确定与采用 Kubernetes 等云原生技术相关的技术目标时，调查受访者将可移植性排在最后，将更直接的问题排在第一位：

改进维护、监控和自动化 - 64.6%。
基础设施现代化 - 46.4%。
更快的上线时间 - 26.5%。
删除供应商依赖项 - 12.8%。
全球覆盖率 - 12.5%。
围绕流量高峰的敏捷性 - 9.2%。
确保便携性 - 8.9%

我喜欢 Google Cloud 的开发者倡导者 Kelsey Hightower 在调查报告中评论这些结果的方式：

很多人认为组织转向 Kubernetes 是因为规模，或者因为他们想成为超大规模者，或者与 Twitter 拥有相同的流量水平。对于大多数组织而言，情况并非一定如此。很多人都喜欢 K8s 中内置了许多决策，例如日志记录、监控和负载平衡。
人们往往会忘记事情有多么复杂，只是为了构建一个没有所有自动化的应用程序。如果你在公有云上，你可以使用一些本机集成和工具。但是，如果你在本地，那不是给定的——你必须自己将解决方案粘合在一起。使用 Kubernetes，你几乎将 25 种不同的工具合二为一。
这就是人们所说的“现代基础设施”的意思——他们并不是在谈论做一些以前从未做过的事情。他们谈论的是过去 10 年或 15 年一直在生产的东西。Kubernetes 是当今所有“现代模式”的检查站。

换句话说，人们真正想要从 Kubernetes 获得的是一种标准的基础设施思考方式。回到 Richardson 之前的观点，虽然 Kubernetes 和云原生技术使公司能够以更高的速度运营，但最大的好处可能是使技能在组织之间可以互换——这为雇主和员工都创造了巨大的绩效收益。这是企业不断增加对 Kubernetes 投资的另一个原因。

声明：我为 AWS 工作，但此处表达的观点是我的。