我们与 Spotify Backstage 的首席工程师就让开发者自愿采用平台工程所需要的激励措施进行了交谈。
译自 How Spotify Achieved a Voluntary 99% Internal Platform Adoption Rate 。
Spotify 工程部门主管 Helen Greul 在接受 The New Stack 采访时表示：“首先出现了微服务革命，这在某种程度上解放了我们。然后 Kubernetes 革命塑造了云原生环境。随着云计算势头渐起，对跨环境的高效编排和管理的需求日益增加。所有这些为团队提供了试验的敏捷性。”
“但有利就有弊，在我们的案例中，开发者的负担日益增加。我亲眼目睹了开发者职责的扩大。”她继续反思促使平台工程崛起的动力。
平台工程是一种社会技术心态和最佳实践、工具链和工作流的集合，旨在减少摩擦并提高开发者生产力。今年，在每个人都试图做更多但资源有限的情况下，这一学科的普及度呈现出流星般的增长。我们也目睹了最受欢迎的开源内部开发者平台 Backstage 的采用量呈指数级增长。
The New Stack 自然而然地与 Spotify 坐下来，了解他们为什么在 Backstage 上投入如此多的时间和资金，并使其开源供其他团队利用。以及他们如何让他们的开发者也乐于使用它。
“作为招聘经理，你首先会雇佣一个能编程的工程师，但随后他们需要编程并交付成果。然后他们需要关注运行时。然后突然之间，他们需要管理跨环境，然后优化。” Greul 说，开发者的责任持续在 Spotify 爆炸性增长和扩展。
大约 5 年前，Spotify 工程部门意识到，仅仅通过雇佣更多开发者已经无法面对复杂性。现代平台工程概念随之诞生，目的是简化软件开发。
“我们在 Spotify 这里有一个平台的平台，这说明我们对此多么痴迷。” Greul 表示 Backstage 是最大的例子，但这家受欢迎的音频流服务还有其他几个内部平台，所有这些平台至少都是内部开源的。
“我认为，如果你正在构建一个面向开发者的产品，要么它将成为一个平台——如果成功且存在时间够长——要么它最终就会消亡。” —— Helen Greul，Spotify
有人会说，2023 年平台工程的兴起表明摆锤效应正在将开发者自治转向以平台为驱动的命令与控制。Greul 并不这么认为。她认为平台是为开发者提供选择的最佳方式，让他们有能力建立自己想要的黄金路径。
“开发者喜欢他们的平台和产品可以扩展。”她说。“我几乎想不出有哪些开发者使用的现成解决方案。”
Spotify 可能在公司文化和创新方面与众不同，但它的第一个目标对于大多数刚刚开始平台工程之旅的公司来说都非常贴切。首先也是最重要的是，他们想要一个目录来明确所有权。
“很难知道大多数微服务的所有者——存在散乱的情况，”Greul 说，“对我们来说所有权的概念非常重要。”所以这个内部开发者平台以一个软件目录开始——只有组件、团队和其他一些抽象，她概述道。这成为最初催生今天我们所知道的 Backstage 的第一块。
接下来——同样并不罕见 —— Spotify 工程团队试图抽象 Kubernetes 的复杂性。初具规模的平台团队正致力于解决编排、管理、部署、测试和健康技术质量等问题。
“这是它在内部爆炸式增长的节点。当我们开放时，”Greul 说。
接下来的需求是提供一站式服务，以了解最终容纳在内部开发者平台中的所有服务，以及清单和发布平台。
如果他们建立起来，他们就会使用它。
Greul 将 Spotify 平台策略的成功归功于其强大的内部开源文化：“任何人都可以自由地为公司内部的任何仓库做出贡献。没有什么代码库是锁定的。”
在这全新的内部开发者平台和关注开发者体验的时尚兴起之前，内部开源从一开始就是 Spotify 的全公司政策，作为确保组织流动性的一种方式。毕竟，她指出，一个有声读物的推出可能会利用多达 50 个不同的仓库。每个人都应该有机会改善自己的开发者体验。额外的好处是：参与建设的人越多，就越有动力去使用它，而不是其他选择——并向同事宣传它。
即使在 Spotify，Backstage 的使用也不是强制性的。“我们试图激励人们，使做正确的事变得更容易。” Greul 继续说道，“正确的事情是标准化，不太多，也不太少，但刚刚好。”
尽管如此，在 Backstage 的发源地，平台工程的采用率很高。但她说这是因为 Spotify 的团队遵循一种理念，即标准可以让你自由。Spotify 版本的 Backstage 在他们所谓的技术雷达中提供了三种前端技术和三种后端技术。
这个工具选择会经常重新评估，包括在季度调查中衡量开发者生产力。他们提供了很大的激励措施来坚持黄金路径，包括在内部广泛宣传成功案例和分享调查结果。
The New Stack 已经写过，这些黄金路径已被证明将 Spotify 的开发者入职时间从 110 天缩短到 20 天。
“作为一个加入 Spotify 的新人，你会在这些标准和模板的指导下完成旅程。” Greul 说，“你可以在某种程度上选择一个或另一个，但有一些警戒线作为你的入职培训的一部分。”
当然，组织内部可能会出现新工具，但她向我保证，Backstage 的即插即用风格允许最佳实践可以相当轻松地集成。
总的来说，在约一年的内部入职和推广后，她认为 Spotify 99% 的开发团队已经采用了 Backstage —— 因为这样做很方便。她指出他们的激励措施或平台即产品的心态是采用率如此之高的原因。
众所周知，Spotify 默认开源，Greul 推测这是因为“如果你想让某件事成为行业标准，软件就无法是专有的”，她认为所有技术标准化，至少在过去十年，都是通过开源路径实现的。这就是 Spotify 如何在 260 多个组织中铺平所谓的黄金路径。
但 Spotify 的公司文化并不普通。Greul 承认，许多其他采用 Backstage 进行平台工程的公司都在努力突破 10% 的采用率。
“他们经常会遇到路障，或者部署可能没有他们希望的那么顺利。”她说，“这就是为什么有时采用会遇到挣扎、停滞，或者无法超越概念验证(POC)的阶段。”
她说这一切又回到了激励上，“开发者必须看到这对他们的日常工作有何益处。” 对于一个创业公司来说，他们使用 AWS 管理控制台的认知负荷可能就很好，不会有改变的动力。“但一旦你达到一定规模，拥有工具来应对认知负荷几乎变得必不可少。” 通常，这时就需要一个 IDP。
你不仅需要说服开发者。业务利益相关者也需要理解，投资平台工程是必要的，以提高开发者生产力。
记住，Backstage 不是万能的现成解决方案。事实上，Greul 说 Backstage 可能不适合单体架构。
但是，在一系列访谈中，我们一直听到开发者对内部开发者平台的首要需求是可扩展性——平台工程与自上而下的命令与控制平台无关。
“Backstage 的独特卖点是你可以使它看起来和感觉起来像你自己的。你可以定制它来解决你的特定需求。” Greul 解释说，“对于开发者来说，通常没有一办法解决所有问题，他们喜欢保持独特的文化、工具和风格，让它看起来和感觉起来像一个自制的解决方案，即使它不是。”
最重要的是，它必须解决他们的问题。他们首要关注的通常是可发现性和标准化。
当然，她指出，这段发现之旅并不是从决定你需要一个内部开发者门户开始的。而是关于明确开发者生产力的挑战是什么，什么让开发者感到压力和熬夜。
归根结底，正如 Greul 所说，“对于一个面向开发者、理解开发者需求构建的产品，他们会认识到其价值，使用现成的就比在旁边做一些奇怪的事情更简单。”