采用平台工程的8个现实理由

每个人都希望更快地交付软件并整合工具和实践。一个考虑这些需求的平台可能会获得更多好处。

译自 8 Real-World Reasons To Adopt Platform Engineering，作者 Steve Fenton。

平台工程 存在一个干净的学术版本。当我们发现随着规模的扩大，倦怠感增加，并将这种倦怠感追溯到软件交付和基础设施复杂性带来的认知负荷时——bingo！——是时候添加平台工程了。

但这种简洁明了的采用路径并不符合现实。采用平台工程的原因很少符合认知负荷类别，了解现实中采用平台工程的动机将有助于那些正在考虑采用平台工程的人。

这个主题正在积极研究中，我将概述我们迄今为止的发现。请也考虑通过提交对我们简短问卷的回复来参与。

谁推动平台采用？

内部开发者平台 (IDP) 可以满足许多业务部门的需求。您可能会找到简化治理、风险和合规要求 或帮助财务部门进行成本控制的方法。但是，推动 IDP 采用的动力几乎总是来自组织内的开发人员和技术领导者。

开发团队的首要驱动因素

工具整合

您的工具链越庞大，您的开发组织越有可能出现碎片化。对于许多团队来说，发现触发工具选择的需要可能发生在不同的时间，而且没有意识到其他团队已经解决了这个问题。在一个大型组织中，捕获和与其他团队共享决策非常困难。您还可能在收购过程中添加团队，他们通常会将自己独特的工具带入其中。

无论原因如何，减少解决相同问题的工具数量 的需求通常是开发团队寻求平台工程时的诱因。

共享最佳实践

在最佳实践集上达成一致是构建内部开发者平台的另一个流行原因。大多数开发团队将共享一组围绕安全、合规性和成本控制的要求，这些要求可以通过内部开发者平台来解决。还有机会为围绕源代码控制和部署管道的最佳实践创建蓝图。

随着这些实践成为专业软件开发的必备条件，开发人员渴望使用使他们更容易实现这些实践的平台。

减少重复

开发人员经常发现，其他团队正在为他们已经解决的问题发明解决方案。他们希望花更少的时间重新发明轮子，而花更多的时间进行功能开发。

这些解决方案的非技术方面可能是平台工程的关键领域。创建黄金路径只是在现有堆栈中添加了另一个解决方案，因此，传达好处与创建出色的开发者体验一样重要。

尽早且频繁地发布

虽然持续交付有很多好处，但开发人员喜欢它，因为它使他们的工作更令人满意。将您的更改快速安全地交付给用户感觉很好。当您永远不会进行大规模合并，以小而易懂的批次工作，并且可以执行无压力部署时，您不再害怕在周一上班（或在周五部署！）。

首要的业务驱动因素

流程整合

当业务领导者希望通过平台来减少开发团队之间的流程差异时，整合的主题就延续了下来。这与标准化略有不同，因为它不是关于强迫团队采用相同的运作方式。相反，平台可以确保实现关键的流程要素。

举例来说，一个团队使用 scrum 而另一个团队使用 kanban 并不重要：内部开发者平台将确保在部署管道中对更改应用相同的策略。

缩短上市时间

业务领导者也希望通过平台来提高上市速度。但是，虽然开发人员喜欢尽早发布，通常是因为它会提高工作满意度，但业务领导者喜欢响应式软件交付的原因却不同。功能可以更早地与用户进行测试，并且可以应用修复程序，而无需特殊的流程来加快速度。

一次性解决问题

对于大型组织来说，很可能会用不同的方法多次解决同样的问题。如果你能够用金钱对这些工作进行估值，那么该平台很可能通过消除这种重复工作来收回成本。当每个团队都负责解决部署管道、基础设施自动化和其他共享问题时，几年内可能会损失功能开发。

这就是为什么企业领导者希望创造一个未来，在这个未来中，这些问题能够得到很好的解决——并且只解决一次。

提高可靠性

现代科技领导者面临的挑战之一是识别何时一切顺利。在过去，解决关键情况的个人技能得到了很好的奖励，但我们现在应该奖励不需要英雄行为的设置。如果您的部署没有压力，并且您的应用程序不会定期崩溃，这可能是您认可团队努力的提醒。

然而，可靠性也是商业领袖考虑平台工程的关键原因。

熟悉的声音需求

平台工程的商业和技术动机反映了相同的需求。每个人都希望更快地交付软件并整合工具和实践。一个考虑这些需求的平台很可能实现进一步的收益，即使它是出于其他因素的动机。

您需要标准化您的技术堆栈，自动化和自助服务才能成功。通过减少范围，您可以降低改进和自动化剩余内容的复杂性。如果您跳过标准化阶段，您只是将负担从开发团队转移到平台团队。

过去强制性的标准化方法从未奏效，并且可能是我们今天看到的一些混乱的原因。当批准的工具链不起作用，并且没有简单的方法来挑战标准时，开发人员面临着要么交付更少要么破坏系统的不可能选择。

平台工程鼓励一种更具响应性的协作方法，其中黄金路径鼓励一致性，但开发人员永远不会被迫在两种邪恶之间做出选择。

意见、研究和实践的融合

我们坚定地处于以研究为基础的软件交付时代。我们已经习惯于从实践者和专家作者那里汲取灵感，但我们现在有机会构建和验证模型——无论是作为行业还是在我们自己的组织内部。

防止这成为纯粹的学术追求至关重要。我们必须将研究建立在现实世界的经验基础上。这意味着培养克服调查疲劳并参与有价值的研究计划（如 Google 的 Accelerate State of DevOps 调查）的勇气。

我们的平台工程研究需要您的意见。虽然我们发现商业团队和技术团队在采用平台工程的原因方面存在共性，但我们也发现了一些信号，例如流程标准化，如果我们没有及早解决这些信号，它们将成为未来的绊脚石。

您可以通过回答我们的简短问卷来帮助我们开发见解。