云原生平台工程的三大悖论

那么,组织如何在这么多埋伏失败的陷阱的情况下实现其软件工作的业务目标呢?

译自The 3 Paradoxes of Cloud Native Platform Engineering,作者 Jason Bloomber 是一位领先的 IT 行业分析师、作者、主题演讲者,在企业技术和数字化转型的多个颠覆性趋势方面获得全球认可的专家。他是数字化转型分析公司 Intellyx 的创始人兼总裁。

云原生计算已经主导了每个需要动态、灵活基础设施规模化的企业 IT。

Kubernetes 和云原生生态系统使企业能够更快、更可靠、成本更低地构建和部署应用程序,但可能很复杂,难以掌握。速度和规模的诺言对于陷入细节的开发团队来说可能似乎不在话下。为了构建这种软件,开发人员需要他们能得到的所有帮助。

DevOps 实践和工具至关重要,但仅仅是起点。为了在云原生环境中取得 DevOps 的成功,组织希望按照仍在萌芽阶段的平台工程最佳实践建立内部开发者平台(IDP)。

平台工程的目标是提高开发者的生产力。如果开发团队具有生产力,那么他们应该能够以业务需要的速度和规模部署软件。

即使有 IDP,云原生开发的目标也为寻求其利益的组织设定了一个高标准。每走一步似乎就是倒退一步。

过分关注开发者生产力会反而适得其反。平台工程可能适得其反地迫使开发者远离。云原生部署变得越来越复杂,管理就越困难。

本文(三篇系列文章的第一篇)将探讨这些悖论。

组织如何在这么多埋伏着失败的陷阱的情况下实现其软件工作的业务目标?

开发者生产力悖论

所有人都同意开发者生产力是一件好事。开发者的生产力越高,他们可以为组织支付的每一美元交付的软件就越多。

然而,开发者生产力的问题在于如何测量它

麦肯锡(McKinsey)最近在一篇有争议的文章"是的,你可以测量软件开发者的生产力"中处理了这个问题,其中理论化了这种测量可以改善软件开发结果。

特别是,麦肯锡认为当开发者将活动集中在构建、编写代码和测试软件上时,他们就是有生产力的。其他"软"活动,包括规划、思考、指导和架构,会吸走开发者的生产力。

从这种观点来看,很明显为什么开发者会反对。任何遵循麦肯锡建议的生产力测量方法都会完全忽略一个事实,即将工作重心放在工作"软"部分的开发者与整天双手在键盘上的同事相比,实际上对其组织整体更具生产力和价值。

像云原生这样复杂的软件计划只会加剧对开发者生产力的这种脱节。在云原生思维模式中,最具生产力的开发者是那些专注于使软件动态化和可扩展化以满足业务需求的人,而与他们花在编码上的时间无关。

开发者不喜欢用拉取请求数量这样的虚荣指标来衡量。为了优化生产力,最好让开发者自己决定应该专注于哪些活动。

平台工程悖论

考虑到市场上大量的 DevOps 工具,组装最佳工具链会让所有人都放慢速度并导致结果不一致。

解决方案: 确保平台工程团队构建一个包含最佳一组用于当前任务的工具的 IDP。这样一个平台的目标是为开发者提供一个"黄金路径"来遵循,本质上是一个推荐的工具和流程集来完成他们的工作。

然而,这个黄金路径可能会成为一个紧身衣。当这个黄金路径过于规范时,开发者会偏离它来完成工作,从而打败了它的初衷。

与测量他们的生产力一样,开发者希望能够对如何编写软件做出自己的选择。

因此,平台工程师在为云原生开发构建 IDP 时必须特别小心。跳到结论,认为适用于其他架构方法的工具和实践也适用于云原生,这可能是一个大错误。

例如,可观测性工具是任何 IDP 的一个重要组成部分,但大多数可观测性工具都不适合云原生开发者的需求。相反,在 Google Cloud 上运行的像 Chronosphere 这样的可观测性工具将为云原生开发者提供完成工作所需的洞察力,即使在复杂和动态的环境中也是如此。

云原生悖论

这种云原生思维为开发者的工作带来了架构方面的关注。

云原生开发者构建单个微服务,但也必须跟踪集群中的 Pod 行为以及集群池中的集群行为。换句话说,他们必须同时关注森林和树木。

开发者的生产力有赖于这种双重关注。任何成功的平台工程工作也是如此。

那么,如何解决这种森林与树木的悖论呢?答案在于数据。在开发微服务的同时保持对大局的适当关注的唯一方法是掌握有关云原生基础设施性能的所有相关数据

然而,太多的数据比太少的数据更糟,这就是为什么来自 Google Cloud 的工具的云原生可观测性以及云原生思维对于实现云原生计算的业务目标至关重要。

Intellyx 的看法

解决这些悖论取决于达到正确的平衡。

过分关注开发者生产力反而适得其反,但太少的关注则会错过改进的机会。答案是: 倾听你的开发者以达到正确的平衡。

过于受限的 IDP 将导致开发者设法绕过它,从而打败其目的。构建遵循云原生思维的 IDP 将有助于达成适当的平衡。

鼓励开发者在大规模云原生计算中把握全局对于实现软件工作目标至关重要,但没有适当的可观测性数据,他们将永远无法在这一全局和日常构建与部署微服务的工作之间找到平衡。

因此,整个云原生思维的概念包含了所有这些平衡行为。倾听你的开发者,给他们正确的数据,让他们找到平衡。

本文在云云众生yylives.cc/)首发,欢迎大家访问。

相关推荐
Karoku06635 分钟前
【k8s集群应用】kubeadm1.20高可用部署(3master)
运维·docker·云原生·容器·kubernetes
探索云原生6 小时前
在 K8S 中创建 Pod 是如何使用到 GPU 的: nvidia device plugin 源码分析
ai·云原生·kubernetes·go·gpu
启明真纳6 小时前
elasticache备份
运维·elasticsearch·云原生·kubernetes
会飞的土拨鼠呀9 小时前
chart文件结构
运维·云原生·kubernetes
Hello Dam13 小时前
面向微服务的Spring Cloud Gateway的集成解决方案:用户登录认证与访问控制
spring cloud·微服务·云原生·架构·gateway·登录验证·单点登录
power-辰南14 小时前
Zookeeper 底层原理解析
分布式·zookeeper·云原生
power-辰南14 小时前
Zookeeper常见面试题解析
分布式·zookeeper·云原生
Cairry.1 天前
WatchAlert - 开源多数据源告警引擎
云原生·开源·prometheus
会飞的土拨鼠呀1 天前
Kubernetes 是什么?
云原生·容器·kubernetes
向阳逐梦1 天前
开源云原生数据仓库ByConity ELT 的测试体验
数据仓库·云原生·开源