这些天，每个人都在谈论平台工程。甚至 Gartner 最近也在其2022 年软件工程炒作周期中对它进行了介绍。但是平台工程的真正意义是什么？它是DevOps发展的下一个阶段吗？它只是 DevOps 或 SRE 的一个花哨的品牌重塑吗？
作为大约十年前的 PaaS（平台即服务）学科的资深人士，以及目前的 DevOps 爱好者，我决定深入研究这个话题，摆脱炒作，看看它在实践中的意义。
什么是平台工程？
平台工程是一种 DevOps 方法，组织在该方法中开发一个共享平台，通过提供具有自动化基础架构操作的自助服务功能来改善整个组织的开发人员体验和生产力。
平台工程可以解决多种不同的需求。核心平台能力通常涵盖运行时环境、Kubernetes 基础设施以及软件发布管道等基础。最重要的是，平台提供了各种功能，例如机密管理、证书管理、自动化 DR（灾难恢复）和混沌工程演习。
一些高级组织甚至将平台工程提升到共享 SaaS 服务（有时称为 SaaS 平台），提供与业务相关的可重用服务，例如计费、计量、云帐户管理和云授权。
平台和应用程序之间的界限在哪里？
George 说得很好：“如果你可以把服务拿给另一个产品团队，甚至给另一个公司，他们可以马上使用，那么它就属于平台。”
平台工程是否取代了DevOps？
正如我们所知，DevOps使用工具来简化部署、管理和使用自动化和可视化的监控。平台工程采用这些工具、流程和最佳实践，并将其产品化为可重复使用的服务和工具，以便在组织的不同工程团队和使用案例中使用。
想象一下，每个产品团队都实施自己的证书轮换机制。这是一个共同的需求，而有一个中央服务来提供它是一个明显的好处。这可以归结为可重复性，这是DevOps成熟度的一个基本要素。在规模上缺乏可重复性是一个明确的信号，表明需要一个平台。正如我常说的。
当你可以重复使用和适应时，不要重新发明。
平台工程随着DevOps的成熟和规模的扩大而出现。为了理解这一点，让我们看一下DevOps成熟度模型，它映射了DevOps转型的历程。常见的DevOps成熟度模型经历了这些阶段。
初始化→管理化→定义化→测量化→优化化
在 "管理 "和 "定义 "的第一阶段，通常每个团队都会创建自己的DevOps实践，以适应其需求。例如，交付物可以是Terraform模板或Terraform模块，然后工程师可以克隆并添加他们的配置，但当他们克隆时，他们会失去与原点的联系。这些解决方案通常是在个别团队内的本地化，与组织的其他部分几乎没有关联。
随着组织的成熟和规模的扩大，它进入了测量和优化的阶段。在这个阶段，企业开始收集数据点，了解其DevOps工具和实践的影响，这就暴露了不同团队分别解决同一问题的低效率的地方。然后，对共享平台进行整合的需求变得很明显。
这是PaaS（平台即服务）的重现吗？
不到十年前，常见的范式将软件栈整齐地划分为IaaS/PaaS/SaaS（基础设施/平台/软件即服务）。平台即服务（PaaS）范式产生了Heroku等工具和AWS BeanStalk和Google AppEngine等云服务，它们为管理应用程序提供了一个统一的现成平台，其方式抽象了底层基础设施的大部分复杂性。
如果你没有听说过这些，这不是你的错。这些PaaS解决方案采取了一种非常有主见的方法来实现这种简单性，事实证明这种方法不够灵活，无法为许多组织的不同实践和偏好服务。Citrix的云平台工程团队在内部经历了这个学习曲线。乔治分享说："我们最初试图建立我们认为是最好的实践，并试图用我们自己的路线图来建立我们的产品。"他们艰难地了解到，这并不可行。
在大型企业中，你经常会发现不同的工程团队采用不同的运行时间、不同的部署方法、不同的可观察性堆栈等。平台通常是在后期出现的，这时这些都已经到位了，要满足这种多样性就需要对平台进行不同的处理。
我们不需要平台作为一种服务。我们需要的是作为产品的平台。
平台作为一种产品
平台工程，与PaaS不同，提供了一个更灵活的方法。首先，它不是一个由第三方供应商提供的通用现成产品，而是一个内部开发。这通常意味着更短的反馈环路，以使新的功能和修改进入平台，并与组织的技术堆栈、方法、实践和合规需求更紧密地结合。
但是，它不仅仅是这样。平台工程将更灵活的方法作为指导原则，让不同的工程团队以不同的方式工作，而不强制要求所有的方式。然而，这并不意味着平台不能认可某些方式。事实上，平台工程经常会选择某种黄金路径，并将其作为最佳支持的选择来推广。
把你的平台当作一个产品，首先要把工程师当作你的用户：了解他们有什么问题，社区和公司内部的情况，以及平台如何为其服务。当你发现一个共同的问题时，你就可以在各个团队中验证这个需求，并量化它将给团队带来的好处。
让我们看看乔治分享的一个例子，一个轮换证书和秘密的服务。在这种情况下。"我看了看团队的积压工作，他们过去实施的所有工作。并尝试看看他们为了轮换机密投入了多少辛劳，加上所有的辛劳和所有的手工工作，你必须在Excel文件中跟踪机密。"
在这种情况下，如果你能向团队展示他们每年在这个功能上投入300个故事点，而整合平台的服务只涉及50个故事点，那么价值案例就非常清楚了。
数据驱动的方法总是最能引起共鸣，尤其是对工程师而言。因此，一定要像其他产品一样，把指标落实到位，以量化你开发的平台能力的成功。这些可以是与开发者生产力相关的，比如减少公关准备时间，或首次代码审查时间，或与开发者体验相关的，用参与度分数或类似指标来衡量。乔治提到，他的团队同时使用领先和滞后指标来实现最佳功能KPI覆盖。
用户研究也会帮助你在平台中找到合适的抽象程度，并在简单性和灵活性之间取得良好平衡。