一句话：开发人员和运维人员真的会交谈吗？还是只是被动地交换Jira ticket？
Spectro Cloud的首席技术官兼联合创始人Saad Malik；Upbound的开发者倡导者Viktor Farcic；Isolater首席开源官Liz Rice和Humantec社区经理Aeris Stewart参与了讨论。
减轻开发人员的认知负荷
DevOps结构中的一个大痛点——跨职能团队中前端和后端的结合——是所有开发人员都不一定愿意或能够承担的额外责任。
Stewart说，许多组织“复制粘贴了这种一刀切的DevOps方法”。
“如果你看看工具领域，工具数量和工具本身的复杂性方面都在迅速增长。同时，开发人员预计将接管越来越多的软件交付过程。所有这些加在一起，对他们来说是太多的认知负荷。”
这种情况对运维工程师也有影响，他们必须帮助减轻开发人员的负担。“这导致了这些组织的很多低效。还有很多DevOps本应消除的低效。
Stewart说，平台工程——运维工程师为开发人员提供一个内部开发平台，该平台可以抽象出一些复杂性，对于那些DevOps难以实现的组织来说，这是“希望的象征”。
Farcic表示，DevOps背后的概念是“让团队自给自足，这样他们就可以完全控制自己的应用程序，从构思到投入生产。”
但他补充道， “你不能指望他们在Kubernetes和AWS等领域有17年的经验。这就是平台的用武之地。这就是其他团队（他们有一定的专业知识）提供服务的方式，让那些开发者和运维人员能够实际完成他们应该做的工作，就像现在的运维人员使用AWS的服务来完成他们的工作一样。对我来说，这就是内部开发人员平台对应用程序开发人员的意义。”
一致性与创新
这些业内人士承认，平台工程一直是DevOps界（以及KubeCon）的热门话题，但其定义仍有点模糊。Rice说：“在许多组织中，‘平台工程’只是一种新颖的表达‘运维’的方式。”
有听众提出了关于DevOps模型的局限性以及平台工程如何融入讨论的问题，询问如何平衡为组织的开发人员提供一致平台的需求，同时允许开发人员进行定制和创新。
Malik表示，在平台工程结构中，一致性和创新都是可能的。“一个组织将决定他们希望在哪里提供抽象。当他们考虑作为一个整体想要在哪里时，他们可以考虑，嘿，当我们提供平台时，我们将提供从安全到GitHub的CI/CD，从存储库管理，这就是如果你使用我们的IDP或平台本身，你会得到的。”
但“将有独特的用例”，Malik补充道，比如正在构建新的区块链技术或运行WebAssembly的开发者。“我认为给那些开发团队运行自己平台的能力是可以的，只要你告诉他们，这些都是你必须负责的领域。你对自己的安全、备份和保留能力负责。”
一位听众提到了Manuel Pais和Matthew Skelton的2019年工程管理书籍《团队拓扑》（Team Topologies），并问小组平台工程是否与DevOps有关，因为它更多的是一种工程管理方法，而不是目的地。
“平台工程正处于其发展的萌芽阶段。”Stewart说，“现在，它真正专注于解决组织在实施DevOps时遇到的问题。”
“我认为，当我们看到社区越来越多地聚集在一起，获得更多关于如何开发平台的最佳实践时，你会看到它不仅仅是一种不同的DevOps方法，而且会变得更加与众不同。但我认为它还没有出现。”
