我们生活在被软件吞噬的世界，而在软件构建领域，几乎每年就会出现一波浪潮。今年，平台工程仿佛成为了一个“新贵”，Gartner 10月发布的2023年十大战略技术趋势中，平台工程就位列其中，它的目的在于为负责构建产品和服务的开发团队提供所依赖的通用共享服务，从而让开发更聚焦于开发，运维聚焦于运维。
平台工程不是第一次尝试解决构建和运行软件方面的普遍难题，也几乎肯定不会是最后一次。之前就有敏捷、DevOps、站点可靠性工程（SRE）和数字化转型，目标宏伟，但结果好坏不一。软件解决方案带来了新问题，许多问题由急切的供应商通过提供带来新问题的解决方案来解决。平台工程试图驾驭创新、采用、碎片化和停滞这个无休止的循环，从而满足不断进步的需求。
1.为什么开发不能DIY？
支持开发项目需要工具，同时保持工程师的高效工作。期望应用程序开发团队运行所有东西不切实际。因此，很多企业团队选择组装一套第三方服务和开源系统，并添加了其他非开发人员以保持系统运行。无论构建什么样的应用程序，都在一个平台上编写它们。
需要一个起点来构建软件。你可以采用数据库、消息队列、容器编排、操作系统和各种开发者工具等框架和工具来搭建应用程序运行的“堆栈”或环境。但特例和偏好会破坏统一性，导致碎片化。因此需要在易维护性和灵活性之间保持微妙的平衡，从而在保持简单易懂的整体环境的同时又能让每个团队发挥所长。
2.DevOps
划分构建和维护软件系统方面任务的简单二分法是分为开发（Dev）和运营（Ops）。开发为客户构建新的特性和功能，运营确保它们在发布后正确运行。
DevOps试图奉行“谁构建，谁运维”的理念，从而消除这种分裂。这种理念认为，通过将运营所有权交给带来软件错误的人（开发者），自然激励会迫使组织正视技术债务，一开始就构建更好的软件。
实践上的挑战在于，DevOps已成为介于Dev和Ops之间的第三个孤岛，处理双方都不想做或不能做的事情。尽管有观点认为“DevOps工程师”一开始就不该存在，但这个角色还是迅速流行起来。它指代这类人：处理搭建持续集成/持续交付（CI/CD）系统、将基础架构配置为代码、为新应用程序配置云环境以及竭力跟上Dev和Ops任何一方面不断出现的变化。
3.站点可靠性工程
SRE概念理论上听起来不错，在适当规模和类型的组织中非常有效。达到足够的规模和复杂性后，确保可靠性本身就成了一项挑战。这个角色常常处理重复的操作任务，并通过采用或构建新的交付和生产力工具和流程来不断识别和消除“脏活”，从而使公司的整体系统逐渐更具竞争力。
实际上，许多组织在实现SRE的承诺时遇到了挫折。有时只是重新命名运营团队，而不改变技能组合或实施可以减少脏活的项目；或者给SRE团队进行改变的余地太小。费用上升（因为更高技能和分配预防性容量的成本高达四倍），而且投资回报多半值得怀疑。
4.数字化转型
对于试图在日益网络化的环境下站稳脚跟的老企业来说，数字化转型概念可能是个宏伟的目标，听起来就像将旧的家庭视频转换成MPEG文件，或扫描纸质合同、改用DocuSign。管理顾问乐于领导这些昂贵、缓慢又痛苦的项目，将组织带入云计算时代。代价高昂的数据泄露增添了暂时的动力，与全球系统集成商签署的多年协议也是如此。不过，数字化转型的最大外在驱动力是疫情，这最终迫使每个人都想方设法使用二维码来点菜。
5.平台来了
“平台”这个词几乎意味着任何东西。首先，平台意味着可以在其上面构建产品。平台随时可供使用。除非组织可以将平台用于多种用途，否则它只是产品的一部分。平台为应用程序、工作负载、租户、运营商、开发者和客户（间接）提供服务。
大多数软件架构现在以“服务”为导向，这也意味着平台必须为服务而存在。可以说平台为在它上面构建产品的其他团队提供服务。
每当我们试图确定“平台”的确切定义时，会开始听起来像是营销噱头。我们可能谈论“计算平台”、“数字基础设施平台”，甚至是“云平台”。我们谈论的平台涵盖一些既模糊又具体的东西：人员、流程、工具、文档、知识、升级路径、供应商合同、SLA、期望、计划和成本结构，这些使组织持续关注平台。
我建议进行以下测试以确定我们是否到底在谈论平台：
- 平台提供有价值的服务
- 平台符合可重用接口
- 平台需要工作负载才有价值
- 平台间接支持最终用户
- 平台提高生产力
- 平台得到资助和维护
- 平台为可靠性、安全性和性能设定了标准
- 平台使得做一些事情变得容易，做其他事情更困难（有意或无意）
- 平台必须谨慎改变，以避免连锁反应
- 平台可能包括手动任务、工单、运行手册和知识
平台通常包括的几类组件如下：
- 基础计算、网络和存储
- 处理定制或随机请求的工单系统
- 身份、身份验证和授权服务
- 准备就绪核对清单
- 安全扫描
- 监控、可观测性和报告
- SLA
- 各种数据库
- 消息队列
- 灾难恢复和故障切换
- 邮件服务器（这有多方便？）
- Kubernetes
如果你的公司没有一个平台团队，那么你们就还没有平台意识。也许你期望供应商为你做一切工作，或者数字化转型顾问集成这些系统，以便无缝地运行，以降低风险、获得很高的投资回报。
值得注意的是，平台工程师已挺身而出。他们试图将文档编写糟糕的工具、服务、开源项目、巧妙的改动、待办列表和技术债务变成类似产品的东西。目标不是虚幻的（“生产力”或“可靠性”），而是务实的（“不妨构建人们想要使用的产品”）。
6.平台即产品
贵公司内部的平台好比推向市场的产品。你想构建贵组织想要使用的东西，因此用户会游说管理层，以确保资源持续不断。所以你需要关注负责重大任务的大型团队，你可以帮助他们加快行动、减少失败并高效运行。你必须了解内部客户的优先事项、痛点、建立规模经济的机会以及可持续的商业模式。你需要使平台易于采用，同时还考虑当前情况的实际限制。
平台采用产品理念可带来与采用 DevOps、SRE、数字化转型或敏捷全然不同的结果。现在有了人们想要使用的东西：平台，它可以减轻他们的负担，并让他们专心致志。他们不必担心云提供的所有细节，他们有一个基于平台的限制和决定的受限菜单。当然，没有人会纯粹为了平台而使用平台；团队必须赢得客户的信任和认可，否则他们只能将工作量带回家。
7.所有权理念
所有权可能根植于人类心理学，也可能是层次化管理结构的产物。在现实世界中，当你尝试运作重大项目时，就要知道谁在做什么，并相信他们会继续做下去。否则，整个组织会分崩离析。一旦没人知道组织结构图，纷争、指责、冷漠和跳槽很快接踵而来。
谷歌的SRE并不负责可靠性，他们大多将自己视为内部可靠性顾问。谷歌SRE试图帮助产品团队在设计系统时做出正确的选择。他们帮助设定服务水平目标（SLO），以确保可靠性目标已明确定义。也许最重要的是，他们推动团队一贯采用来自整个谷歌技术基础架构（可以称之为平台）的标准服务。SRE是平台即产品的客户成功团队。
8、下一步是什么？
平台工程潮流越来越盛。LinkedIn和Twitter上将“平台”添加到头衔中的人越来越多。CEO们将平台工程师视为主要客户。
当我试图更好地了解当下的形势时，我问了所有的SRE朋友他们对平台工程有何看法。每个人都会怀疑这是新瓶装旧酒，只是营销噱头。
不止一个SRE告诉我“实际上，我们是平台团队，而不是SRE团队。”我认识的以前在性能工程、安全和数据管理方面工作的朋友和同事都已经向平台工程转型。
我最喜欢平台工程的是所有权，最不喜欢的是平台工程在定义方面的模糊性，诸如在“平台是什么、不是什么”方面缺乏明确性。我对DevOps穷途末路和SRE一败涂地的说法持保留态度。DevOps工程师的工作仍然需要完成，即使换了新名字。想象一下平台团队在你的公司聚在一起，接管其他产品、应用程序和IT团队面临的常见问题，结果会如何。
平台不是一艘更快的船，而是上涨的潮水。
原文链接：
https://dzone.com/articles/the-rising-tide-of-platform-engineering
