笔者: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 工作,但此处表达的观点是我的。

文章统一发布在公众号云原生指北


云原生指北
25 声望7 粉丝