3个平台工程悖论：如何解决日益增长的复杂性和有限精力之间的矛盾

对于需要大规模动态、灵活的基础设施的组织来说，云原生计算已经主导了企业 IT。Kubernetes 和其他云原生生态系统使公司能够更快、更可靠、以更低的成本构建和部署应用程序，但可能会很复杂，难以掌握。当开发团队陷入鸡毛蒜皮的工作时，软件开发速度将会被延缓。为了构建这样的软件，开发人员需要得到他们所能得到的一切帮助。

DevOps 实践和工具是必不可少的，但仅仅是起点。为了在云原生环境中成功地使用 DevOps，组织希望按照以平台工程的最佳实践来构建内部开发人员平台（IDP）。

平台工程的目标是提高开发人员的生产力。如果开发团队是富有成效的，那么他们应该能够以业务所需的速度和规模部署软件。然而，即使有了 IDP，云原生开发的目标也为组织设置了很高的门槛。每向前走一步，他们似乎就后退一步。

过度关注开发人员的生产力可能会适得其反。与直觉相反，平台工程可能会让开发人员感到排斥。云原生部署越复杂，管理起来就越困难。

01 云原生平台工程的三个悖论

开发者生产力悖论

每个人都同意提升开发人员的生产力是一件好事。开发人员的生产力越高，他们就能交付更多的软件。

然而，开发人员生产力的问题在于如何衡量它。McKinsey 在最近一篇有争议的文章 “Yes, you can measure software developer productivity”[1] 中探讨了这个问题。文章特别指出，当开发人员将他们的活动集中在构建、写代码和测试软件上时，他们是高效的。但同时计划、思考、指导和架构等“软”活动，会削弱开发人员的生产力。

因此，任何遵循 McKinsey 建议的生产力衡量方法都将完全忽略这样一个事实: 与那些把所有时间都花在键盘上的同事相比，那些把精力集中在工作“软”部分上的开发人员实际上更有生产力，对整个组织更有价值。

像云原生这样的复杂软件计划只会加剧这种与开发人员生产力的脱节。在云原生思维中，最高效的开发人员是那些专注于满足业务需求的动态和可扩展软件的开发人员，而不管他们花了多少时间写代码。

开发者不喜欢用一些虚荣的指标来衡量，比如 PR 的数量。为了优化生产力，最好让开发人员自己决定他们应该关注哪些活动。

平台工程悖论

考虑到市场上大量的 DevOps 工具，组装最佳的工具链可能会拖慢每个人的速度，并导致不一致的结果。

解决方案则是——确保平台工程团队构建一个 IDP，其中包括针对手头任务的最佳工具集。这样一个平台的目标是为开发人员提供一条“黄金路径”，本质上是一组推荐的工具和流程，用于完成他们的工作。

然而，这条“黄金路径”也可能成为束缚。当这条黄金路径过于规范时，开发人员就会为了完成工作而不再采用它，从而违背了它的目的。

正如衡量他们的生产力一样，开发人员希望能够就如何制作软件做出自己的选择。因此，平台工程师在为云原生开发构建 IDP 时必须特别小心。认为适用于其他架构方法的工具和实践也适用于云原生可能是一个很大的错误。

云原生悖论

云原生的思维方式让开发人员开始关注架构。

当云原生开发人员构建单独的微服务时，也必须密切关注集群中的 pod 和集群中的集群的行为。开发人员的生产力依赖于这种双重关注。任何成功的平台工程工作都是如此。

那么，如何两者兼顾的矛盾呢？答案就在数据中。在开发微服务时，要保持对全局的适当关注，唯一的方法是掌握有关云原生基础架构性能的所有相关数据。

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

02 云原生的平台工程是不同的

为云原生计算创建一个内部开发人员平台 (IDP) 是具有挑战性的，因为云原生计算是独特的和复杂的，因此要正确使用并不简单。

然而，正确使用它是为业务实现云原生优势的关键，它使开发人员能够更快、更可靠、更低成本地构建和部署应用程序。因此，理解为什么开发者平台对于云原生计算是不同的，这是正确的第一步。

云原生差异

云原生应用程序与传统应用程序明显不同，主要是因为它们是为云原生“向外扩展”基础设施设计和开发的，通常使用多个云提供商服务。

公有云提供商提供数百种系统软件服务，其中任何一种都可能与手头的任务相关(或不相关)。对这些服务进行分类以确定需要合并到 IDP 中的服务可能非常耗时。

此外，开发云原生应用程序通常涉及将功能分解为微服务，将微服务代码打包到带有所需构件的容器镜像中，并将容器部署到 Kubernetes 集群。但是当涉及到微服务、容器和 Kubernetes 支持时，所有的软件工具都有所不同。传统工具通常不支持云原生开发人员，因为它们不是为微服务容器和 Kubernetes 的云原生环境设计的。

成功采用微服务

微服务是一个离散的工作单元，通常是一个应用程序特性或功能。微服务公开 API 来封装其功能，并通过网络与其他微服务交互。云原生开发人员需要快速、大规模地开发和部署微服务，以跟上现代变化的步伐，他们需要快速响应客户反馈和事件。

成功采用微服务的组织通过由中央 IDP 支持的小型自治团队获得了最大的收益，该平台执行组织标准和一致的工具。例如，修补和更新单个微服务要比仅仅为了修复一个 bug 而重新部署一个整体应用程序容易得多。

这种模式的成功需要正确的组织结构和治理，仔细协调影响多个微服务的突破性变化的纪律，以及在 IDP 中正确组合云原生技术和工具。

面向云的平台工程

平台工程的目标是创建一个 IDP，它可以作为开发人员的产品，抽象出基础设施问题和工具问题。由于云原生环境与传统IT环境的差异，这些抽象必须与微服务、容器、Kubernetes 和云厂商服务一起工作。

云原生最佳实践给开发人员带来了额外的责任。例如，在传统的IT环境中，开发人员要求运维团队提供他们需要的数据库、事件存储和 secrets vaults。云原生环境则没有运维团队来手动提供所需软件。

而开发人员使用的IDP可以暴露声明式 API、配置文件和脚本，以便开发人员可以自助服务。考虑一个提供数据库的请求。SRE工程师或运维团队将在 IDP 中建立可用的数据库，以满足安全性、可用性和可靠性问题以及开箱即用的监控。

例如，开发人员声明了对关系数据库的需求，而不必指定是哪一个。这种抽象级别允许将数据库换成另一个数据库，而不会影响应用程序。

云原生开发的可观测性

让我们假设您在云原生环境中工作，并使用容器和 Kubernetes 开发微服务。

假设您遵循了将开发人员组织成在整个开发生命周期（包括生产支持）中负责至少一个微服务的小型自治团队的最佳实践。

所有这些都是为了提供出色的客户体验，快速开发和部署，提高开发人员的生产力，并以更高的质量和弹性更快地将应用程序代码发布到产品中。这些选择的成功在很大程度上取决于在 IDP 中纳入正确的可观测工具。

传统的可观测性工具只监控部署后的代码——也就是说，它们监视预发布(staging)和生产中的代码。当然，这很重要，但是减少事故和故障的数量也很重要，这些事故和故障占用了开发和部署代码的时间，从而提高了客户体验和业务竞争力。

简单地捕获数据的可观测性解决方案效率低下，而且会妨碍生产力。微服务、容器和 Kubernetes 的云原生世界需要一个专门为开发、部署和支持微服务的小型自治团队过滤和定制数据的解决方案。

03 云原生是否会改变开发人员的工作效率和体验?

云原生开发始于微服务。虽然微服务有很多定义，但更为流行的定义是“简约、内聚的执行单元”。

“简约”的意思是尽可能小，“内聚”意味着每个微服务都能很好地完成一件事。“执行单元”指的是在容器中运行的微服务包含执行所需的运行时组件这一事实——这与早期的 web 服务形成了鲜明对比，后者是基于 XML 的软件端点，需要企业服务总线(或其他技术，如 servlet 引擎)来提供执行上下文。

此外，在更广泛的云原生架构上下文中，微服务需要额外考虑。它们在 pod 内自动伸缩，因此开发人员必须将它们设计成无状态的。因此，用微服务管理状态需要特别小心，以获得弹性扩展的优势。

为了保持生产力，云原生开发人员必须与 DevOps 团队合作，随时跟踪每个微服务的所有这些微服务属性，记住每个微服务在更广泛的云原生架构环境中的功能。换句话说，云原生开发既困难又复杂——这些挑战很容易影响开发人员的生产力和 DX（开发者体验）。

在充满挑战的发展中保持 DX

不过，开发者普遍喜欢挑战。他们中的大多数人选择自己的职业，是因为解决难题可以带来满足感。当一段特别困难的代码最终按照预期的方式运行时，没有比这更好的感觉了。

然而，在有趣和令人满足的挑战与难以解决的问题之间存在着细微的差别。对于许多开发人员来说，云原生开发像是在不断碰壁。

开发人员的生产力和 DX 都取决于将这个等式转向开发人员喜欢的各种挑战。IDP 可以提供帮助，因为它们为开发人员提供了一组推荐的工具，但拥有正确的工具至关重要。

参考链接： 

[1]https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity