5

平台工程的 3 个悖论 - 运维 - dbaplus社群：围绕Data、Blockchain、AiOps的企业级专...

 6 months ago
source link: https://dbaplus.cn/news-134-5923-1.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

平台工程的 3 个悖论

Jason Bloomberg 2024-03-15 10:08:18

云原生已经成为需要大规模动态灵活基础设施的 IT 企业的主导力量。

Kubernetes 和其他云原生生态系统使公司能够更快、更可靠、更经济地构建和部署应用程序，但也会增加复杂性而且难以掌握。当开发团队陷入细节时，对速度和规模的要求似乎就难以实现了。为了构建这样的软件，开发人员需要尽可能多的帮助。

图片

DevOps 实践和工具是必不可少的，但这也仅仅是一个起点。要在云原生环境中成功实施 DevOps，团队希望遵循仍处于萌芽阶段的平台工程最佳实践来构建内部开发人员平台 (IDP)。

平台工程的目标是提高开发人员的生产率。如果开发团队高效，那么他们就能够以业务所需的速度和规模部署软件。然而，即使有了 IDP，希望使用云原生带来好处的组织也面临着很高的门槛，似乎没前进一步，就会后退一步。

过度关注开发人员的生产力可能会适得其反。平台工程可能会让开发人员远离。云原生部署变得越来越复杂，管理起来也就更加困难。本文是三篇系列文章中的第一篇，将探讨这些悖论。

当如此多的陷阱威胁着团队的时候，那么我们应该如何实现软件项目的业务目标呢？

开发者生产力悖论

每个人都同意提高开发人员的生产力是一件好事。开发者的工作效率越高，组织支付给他们的每一分钱就能交付的软件就越多。但是开发人员生产力如何来衡量它呢。

麦肯锡在最近一篇有争议的文章《是的，你可以衡量软件开发人员的生产力》(https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity)中探讨了这个问题，该文章认为这种衡量可以改善软件开发成果。

麦肯锡特别指出，当开发人员将他们的精力集中在构建、编码和测试软件上时，他们就会变得非常高效。其他“软性”活动，包括规划、思考、指导和架构设计，都会降低开发人员的生产力。

从这个角度来看，开发者的抵制原因就很明显了。任何遵循麦肯锡建议的生产力衡量方法都将完全忽略这样一个事实：将精力集中在工作的“软性”部分上的开发者事实上比那些整天用键盘操作的同事更加有效率和对组织更有价值。

像云原生这样的复杂软件项目只会加剧这开发者生产力上的这种脱节。在云原生思维中，最有效率的开发者是那些专注于创造动态和可扩展软件以满足业务需求的人，而不是看他们花了多少时间编码。

事实上开发人员不喜欢用诸如 pull request 数量之类的虚荣指标来衡量。为了优化生产力，最好让开发人员自己决定他们应该关注哪些活动。

平台工程悖论

鉴于市场上存在大量的 DevOps 工具，组装最佳工具链可能会拖慢所有人的速度，导致结果不一致。

解决方案：确保平台工程团队构建一个包含最佳工具集的 IDP。这样一个平台的目标是为开发人员提供一条可以遵循的“黄金路径”，本质上是一套推荐的工具和流程来完成他们的工作。

然而，这条黄金路径也可能变成一种约束。当这条黄金路径过于规范时，开发人员就会为了完成工作而偏离它，从而达不到它的目的。就像衡量他们的生产力一样，开发人员希望能够自己选择如何打造软件。

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

例如，可观测性工具是任何 IDP 的重要组成部分，但大多数可观测性工具并不能满足云原生开发人员的需求。相反，像 Chronosphere 这样在 Google Cloud 上运行的可观测性工具将为云原生开发人员提供他们所需的洞察力，即使在复杂和动态的环境中也能完成工作。

云原生悖论

云原生的思维方式将架构重点放在开发人员的工作上。

云原生开发人员构建单独的微服务，但还必须密切关注集群中的 Pod 以及集群的行为。换句话说，他们必须同时关注全局和细节。

开发人员的生产力取决于这种双重关注。任何成功的平台工程也是如此。

那么，如何解决全局和细节之间的这种悖论？答案在于数据。在开发微服务时保持对云原生基础设施性能的所有相关数据的掌握，是在保持对整体情况的适当关注的唯一方法。

然而，过多的数据比过少的数据更糟糕，这就是为什么云原生可观测性工具带来的云原生思维方式对于实现云原生计算的业务目标至关重要。

总结

解决这些悖论取决于适当的平衡。

过多关注开发人员的生产力会适得其反，但太少则会使改进的领域被忽视。答案是：倾听你的开发者，找到正确的平衡点。

过度受限的 IDP 将导致开发人员寻找绕过它的方法，从而失去了其目的。建立一个遵循云原生思维方式的IDP将有助于实现适当的平衡。

鼓励开发者把握云原生全局至关重要，但如果没有正确的可观测性数据，他们永远无法在构建和部署微服务的日常工作与整体之间找到平衡点。

因此，云原生思维的整个概念包含了所有这些平衡行为，倾听开发人员的意见，为他们提供正确的数据，让他们找到平衡点。

来源丨k8s圈（ID：kube100） 原文地址丨https://thenewstack.io/the-3-paradoxes-of-cloud-native-platform-engineering/ dbaplus社群欢迎广大技术人员投稿，投稿邮箱：[email protected]

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK