翻译 KubeCon Panel: How Platform Engineering Benefits Developers 。

KubeCon 小组解释了平台工程，以及为什么拥抱这种新的 DevOps 趋势符合开发人员的最大利益。

如果说 DevOps 是将运维和开发工作流程相结合的话，那么平台工程旨在解决由此产生的问题。这不是两者之间的二选一，而是一个 DevOps 运动的演变，一场 KubeCon+CloudNativeCon Eu 的小组讨论这样说道。

“我有时会对为什么某些事物必须消亡以便其他事物存在感到困惑，” GitLab 的首席产品官 David DeSanto 说道。“对我来说，平台工程的本质是确保您的 DevOps 团队与平台更有效地合作，两者之间存在很多重叠和价值，这是一个相互促进的关系。”

HashiCorp 欧洲、中东和非洲地区首席技术官 Sarah Polan 说，从非技术意义上讲，平台是支持您尝试做的任何事情的东西。

“因此，在 IT 领域的情况下，这些是您要构建的基础组件，以创造业务价值并解决您的业务问题，” Polan 说道。“在我们的案例中，这些都是部署和提供 Terraform 作为产品所需的所有小部分，这就是我们的团队所依赖的，为了能够做到这一点而消费的。”

DeSanto 建议，产品实际上可以是平台。

“至少对于我们在GitLab来说，平台就是产品。我们的平台团队专注于 gitlab.com ，这就是我们的产品，”DeSanto说道。“所以我认为这取决于您在与谁交谈——谈话中的客户是谁？”

该小组还同意，平台工程是一种实践，而不是可以购买的东西——他们警告说，尽管有些人会试图把它卖给你。

“平台工程可以是我们正在承担的一个角色，类似于 DevOps ，而我相信——并与我的同行交流——它确实是其延伸，是我们所做的事情的一个扩展。它是进化而来的，不一定是革命性的，”红帽混合平台营销洞察总监 Stu Miniman 说道。

Polan 说，平台工程是关于应用最佳实践并确保对开发组织及其使用的工具进行一定程度的控制。

“当时我在一家金融机构工作，当时在运行 Go 应用程序，所以它并没有受到 Log4j 的影响，但我仍然在半夜接到了三个电话，因为...我们需要确保一切都得到了适当的修复，” Polan 说道。“这确保我们作为组织拥有适当的控制，但同时也要基于此获取商业价值，并设置防护措施来说，‘我们希望您能够做您想做的事情。我们希望您遵循行业标准，使用开源软件，但我们也希望确保我们对这些事情有足够的控制力。’”

该小组指出，通过拥有一组经过批准的工具和库选项，组织可以更快地吸纳开发人员。开发人员自然喜欢尝试新工具——这是他们的工作的一部分，曾经担任开发人员的 DeSanto 说道。问题在于，每个开发人员引入新工具，以及针对这些工具的集成，可能会导致工具泛滥，他说。

他说：“你最终会伤害安全和效率。你本质上是要求那些专业不是管理基础架构，以及所有内部 CI/CD 流程的人自己做决策，但这不会给他们最好的结果。”

Polan 说，在一个流失率为 20-23% 的市场中，这成为一个令人头疼的问题。

“很快就会有人感到沮丧，意识到他们可以去街对面找到另一份工作，” DeSanto 补充道。“因此，如果您正在建立真正适合他们[开发人员]的东西，他们将更加参与。您将获得更好的公司成果。您希望有更快乐的员工，更快乐的员工也等于更多的收入。”

平台工程是一个看似新的运动，但实际上已经成长了三年，Miniman 表示。在过去的三年中，两个变化因素是远程工作的增加和现在即使是“小商铺”也成为技术公司以保持竞争力，小组表示。仅仅构建一个单体应用并将其放置 20 年已经不够了。

“ 15 , 20 年前，我们实际上构建的东西非常不同，变化的速度和反应能力也不同，” Miniman 说道。“现在我不能再构建一个定制应用并将其放置十年，因为那样做会使我处于竞争劣势。”

Polan 使用“可演化性”一词来描述公司为什么应该拥抱平台工程。虚拟化、5G和面向服务的架构正在创建一个需要灵活性和模块化的开发环境，Polan 说。

她说：“这也将反映在平台团队中...通过将这些任务交给平台团队，我们可以扩展一些解决方案，同时也具备推进事物的灵活性。这给了我更好的选择，使我更加响应迅速，显然给了我更好的投资回报和更好的安全性。”

但也许最大的原因是，开发人员应该拥抱平台工程的原因在于，它减少了当前编程的认知负荷， Miniman 表示。

如果我们能让事情变得简单一些，让开发人员专注于他们的主要角色和他们想要做的事情，那就会使事情变得更容易，”他说。