平台工程是突破还是失败？关键在于“平台即产品”心态！聚焦IDP的采用和扩展，通过消除认知负荷赋能开发者。未来趋势：拥抱开源/SaaS，AI驱动，关注可组合性。自建平台需兼顾灵活性、抽象化和集中治理。DevOps演进，为工程师构建卓越体验才是王道！
译自：Platform Engineering on the Brink: Breakthrough or Bust?
作者：Jennifer Riggins
当平台工程处于悬崖边缘时，它是否正处于跌入Gartner的幻灭低谷的边缘？它最终会弥合业务和技术之间的鸿沟吗？还是会在2025年失宠并陷入投资不足的境地？未来两年会是什么样子？
如果（根据最新的DORA报告）89%的组织已经在使用某种形式的内部开发者平台，那么平台工程的未来在于你如何交付开发者想要的东西。Booking.com的Shweta Vohra、OpenCredo的Nicki Watt、Chainalysis的Leena Mooneeram和Syntasso的Paula Kennedy在伦敦举行的State of Open Con的小组讨论中表示，一切都与开发平台即产品的心态有关。
当然，你的平台工程项目的寿命取决于衡量其对软件开发生命周期的影响。
小组成员预测，在未来两年内，平台工程的创新将围绕构建和维护平台意味着什么。小组成员表示，平台工程团队将通过让开发人员采用和扩展内部开发者平台（IDP）来帮助他们减少自身的认知负荷。
随着这一趋势进入第三年，业界才刚刚开始围绕平台工程的定义达成一致。
OpenCredo的CEO兼CTO Watt表示，如果平台工程试图完成一件事，那就是减轻开发人员在尝试交付软件时所经历的认知负担。
她说，平台工程是“DevOps的演变，旨在尝试减轻开发人员的一些繁重工作，因此你可以专注于构建交付给用户的软件。”这种非差异化工作的范围可以从启动基础设施和云环境到整合和标准化开发工具的蔓延，从而形成“一条铺平的道路或明智的前进方式，以便我们可以作为一个工程团队前进。”
为了在资金紧张的时期保持平台团队的预算，小组成员建议，他们必须成为倍增器，部分原因是通过消除干扰。
Chainalysis的高级工程师Mooneeram说：“我们尝试研究那些常见的模式——你重复执行的繁琐任务——以及我们如何抽象它们并消除认知负荷。”
她说，随着她的组织规模远远超过初创公司，平台工程战略能够实现对齐。
“我们正在研究一种工程师拥有很大自主权的局面，并且我们有很多很多工具。但是，为了让平台真正能够做出贡献并成为倍增器，我们必须找到这种对齐和共性。”
为了取得成功，平台工程团队还必须支持和衡量业务目标。
Booking.com的企业架构师和“Decoding Platform Patterns”的作者Vohra说：“我们行业目前面临的最大挑战之一是我们支离破碎的技术生态系统。我们正在快速发展、不断更新，最重要的是，我们正在处理不断发展的业务模式。”
“平台工程正在帮助我们抽象至少两个问题，如果不是全部的话。它肯定应该为我们管理支离破碎的技术，并跟上企业处理的不断发展的更新。”
她认为，如果平台未能成功隐藏技术复杂性，它就无法实现其目的。
平台工程首先是关于工程的，这使其成为一门科学，这意味着你无法改进你无法衡量的东西。 “如果我们没有加速数字化转型，反而减慢了它的速度，也许是我们设计的方向不对，”Vohra说。另一方面，她补充道，“我们需要停止将我们的内部平台或所有这些平台工程的东西视为次要的。我们需要像对待任何业务平台一样对待它。”
对于Chainalysis以及许多平台团队来说，其中一个关键指标是IDP的采用率和使用率。
Mooneeram说：“这是一个代理指标，可以确保我们实际上交付了我们的工程师想要的解决方案。如果没有更深入的、定性的信息调查，我们无法快速找到这些信息。”
小组成员一致认为，确实需要定量和定性测量的结合。这些可能包括：
Watt建议寻找对立的指标，比如确保不要以牺牲质量为代价来关注速度。此外，她说，你也不想一次测量太多的东西，以至于你无法识别出对开发者体验造成最大损害的因素。
你还需要明确你的目标，在一些公司，这可能是一个更传统的平台对安全和标准执行的关注，这意味着你的衡量方式将与你优化开发者生产力的方式大不相同。
平台所承诺的现在实现了吗？小组成员明确地表示：没有。
当平台团队专注于构建与内部开发者客户需求不匹配的技术解决方案时，他们就会失败。他们没有将他们的平台作为产品来对待。
Mooneeram说：“我认为这是我们目前在平台工程中面临的最大问题，但我也认为这是我们最大的机会”，甚至提倡在平台团队中拥有产品负责人或产品经理。“我们似乎从以更加以客户为中心的角度来看待它，并由那些具备这些技能的人来做，这给我们带来了主要的好处。”
Kennedy注意到“名义决定论”的力量，然后回顾了Sam Newman（一位著名的作家和顾问）在2023年发表的一篇名为“不要称其为平台”的博客文章：
“我真希望他们没有将平台团队的概念编纂成典。命名很重要——它推动了一个方向——‘我们存在是为了构建一个平台’，”Newman写道。然而，他补充说，正如团队拓扑一书概述的那样，这并不是平台团队的真正目的：“平台团队的任务，如果你选择接受它，是关于使这些与流对齐的团队能够完成工作。”
当团队陷入为平台而构建平台时，Kennedy说，产品思维就不在考虑范围之内了。
Mooneeram说：“我们非常幸运。我们与我们的客户在同一家公司工作，因此我们需要非常努力地获取这些信息并建立这些关系，这样，当你展示一个新产品时：首先，他们已经知道它要来了。其次，它是他们真正需要的，并且正在填补一个空白。”
Watt建议询问你的内部开发者客户：
- 什么最阻碍你？
- 如果你可以改变你工作中的一件事，那会是什么？
随着平台工程越来越受欢迎，毫不奇怪，平台工具的范围也越来越广，开源或专有、自建与购买的辩论将在未来几年内继续进行。
Vohra说：“围绕开源工具的竞争和组合有很多，这就是我们首先要处理这种技术思维的地方，而不是抽象化这种技术。”
她看到大多数组织都在学习DIY解决方案，包括在Booking.com。“这给了我们灵活性。在某些地方，工程师希望按照自己的方式处理、学习和引入人工智能。严格地给他们一些抽象，只是隐藏了所有的内部结构，这对他们不起作用。”
她继续说，自建平台能够实现：
- 灵活性。
- 抽象化。
- 集中治理。
- 去中心化。
到目前为止，她认为，软件即服务（SaaS）产品根本无法带来与自建解决方案相同的好处。
此外，Kennedy评论说，“工程师总是会进行工程设计”，这就是为什么自建往往对大多数平台工程师具有吸引力。 Mooneeram表示赞同，但平台团队通常人手不足。因此，她预测在未来两年内，将会出现一种趋势，即采用现有的开源甚至专有工具，这些工具具有一定的灵活性和可扩展性——“一种组织特定的包装”——而无需从头开始构建。
Watt表示，虽然Cloud Native Computing Foundation (CNCF) 的格局，就像宇宙一样，似乎在无限扩张，但这部分是因为许多不同的工具适用于非常具体的情况。
然而，她补充说：“可能会有一两个工具变得更加突出，在某些情况下更有帮助。我认为可能会有一些SaaS产品实际上很有帮助。也许它们建立在一些开源工具之上。但对于刚起步或规模很小的组织来说，它们真的很容易启动并运行。”
与所有工程技术一样，技术只是故事的一部分。
Watt拥有超过十年的云原生计算咨询经验，她观察到一种模式，即组织最初会成立一个平台团队来减少摩擦。但随着它们的扩展，平台团队的数量也会增加。
她说：“你越大，你试图覆盖的表面积就越大，你就越不可能拥有一个平台团队。从组织的角度来看，你可能会发现你得到的平台团队可能正在关注平台内的不同类型或领域”，例如云、可观测性和内部开发者门户。人工智能和数据团队通常需要完全不同的平台设置。
“我们非常幸运。我们与客户在同一家公司工作，因此我们需要非常努力地获取这些信息并建立这些关系，以便当你展示新产品时：首先，他们已经知道它即将推出。其次，它是他们真正需要的，并且正在填补空白。”
– Leena Mooneeram, Chainalysis
甚至工程管理指南“团队拓扑”的合著者Matthew Skelton也表示，他希望他将其称为“平台分组”，因为它很少只是一个平台团队。
Mooneeram在谈到她在Chainalysis的平台团队时说：“我们实际上是数据平台组织中的一个平台团队。所以感觉我们无论如何都是嵌套的，所以很多团队实际上都在那里培训其他人。”
另一方面，对于初创公司来说，一个平台工程师可以完成很多工作。
Mooneeram说，随着你的成长，你需要一个内部开发者倡导者，他可以担任某种产品负责人或平台内部营销角色。这个平台即产品角色还应该提高知名度，以便这项工作可以内部开源，应用程序团队可以为平台做出贡献。
当然，从现在开始的两年后，构建平台的不仅仅是开发人员。Watt预测人工智能代理将嵌入到整个过程中。她说，平台也将继续变得更具可组合性。
Vohra提出了更多预测：“我可以看到平台工程的发展轨迹与我们看到的DevOps相同，从概念到运动再到现实。我希望看到更多努力的整合，更多经验的积累，因为未来不属于那些仅仅使用人工智能快速构建的人。
“未来属于那些为工程师和开发人员构建经验的人，以便它为企业服务，因为它将加速他们的业务，当然也为工程师服务。”