开发者不想做运维，对 DevOps 来说不是好事情。
最近， Scott Carey 发表了一篇调查文章，喊出了一些开发者的心声：“扯淡的DevOps，我们开发者根本不想做运维！”除此之外，软件工程师兼 DevOps 评论员 Sid Palas 也在推特上写道，“DevOps 已死，平台工程才是未来。”
他的核心观点是：开发者不想跟基础设施打交道，企业在发展过程中又需要控制自己的基础设施。只有平台工程，能将这两个相互矛盾的命题统一起来。
Honeycomb 的首席技术官 Charity Majors 对此也有同样的观点，她认为在软件演进过程中，我们将运维技能从开发技能中剥离出来，形成了两个不同的职业，但结果证明这是一个巨大的错误。因此 DevOps 出现了，我们用它来重新统一开发和运维。然而开发周期应该是一个企业中最稀缺的资源，所以应该将尽可能多的资源花在核心产品上。
Majors 认为，在过去，有的工程师写代码，有的工程师跑代码。而现在，工程师不仅编写代码，还要运行他们编写的代码。这导致软件工程师觉得他们必须对所有事情都了如指掌，大大增加了“认知负担”。
这迫使许多团队重新在自动化带来的自由与认知负担之间进行权衡。平台工程也因此越来越受关注和热议。PlatformCon 是第一个面向平台工程师的会议，一出现就吸引了超过 6,000 名与会者。Gartner 也在其 2022 年 8 月发布的软件工程炒作周期中添加了“平台工程”（图中第四个小圆点）。
按照“平台工程”社区主要贡献者和 Humanitec 的产品负责人 Luca Galante 的说法，平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。平台工程师提供集成化产品，通常称为“内部开发平台（Internal Developer Platform）”，可以涵盖应用程序整个生命周期的所有操作需求。
内部开发平台（以下简称 IDP）是位于工程团队已有技术和工具之上的一层。它帮助操作人员进行系统性设置，并为开发人员提供自助服务。平台工程做好了，就好比是为个体开发人员铺就了金光大道，他们可以从 IDP 层获得合意的抽象等级。
从 DevOps 余烬中崛起DevOps 和云原生的概念兴起之后，似乎是在突然之间，工程师们不得不掌握 10 种不同的工具、Helm 图表、Terraform 模块等，仅仅是为了在多集群微服务设置中的多个环境中部署和测试一个简单的代码更改。问题是，在整个工具链的演进过程中，这个行业似乎认为，在全球经济的几乎其他所有领域都被证明有效的劳动分工（Ops 和 Dev）并不是一个好主意。相反，DevOps 范式备受推崇，被视为实现高效设置的方式。
开发人员应该能够端到端地部署和运行他们的应用。“谁构建，谁运行”，这才是真正的 DevOps。这种方法的问题是，对于大多数公司而言，这实际上并不现实。
虽然对于像谷歌、亚马逊、Airbnb 这些比较先进的组织来说，上述方法很有效，但对于其他大多数团队而言，要在实践中复制真正的 DevOps 并不简单。最主要的原因是，大多数公司都没有像他们那样的人才库，也不会仅仅为了优化开发工作流和体验而做他们那样的资源投入。
与此相反，当一个普通的工程组织试图实施真正的 DevOps 时，往往会出现一系列的反模式。我们通过一个例子来看下，当组织决定实施 DevOps 并取消正式的 Ops 角色或团队时，许多开发团队中出现了什么情况。开发人员（通常是比较资深的）最终承担起了管理环境、基础设施等的职责。这就导致了这样一种情况：“影子操作”由那些在编码和产品开发方面才能体现出最大价值的工程师来执行。没有赢家。高级工程师现在要负责设置，并需要处理比较初级的同事的请求。在组织层面，其最昂贵和最有才华的资源现在正在被滥用，他们无法再以同样的速度和可靠性来交付功能了。
