平台工程不仅仅是关于工具链或内部开发者平台。在其核心，它是一门可以提高开发者生产力的学科。

翻译自 Platform Engineering Is a Bandwagon Worth Jumping on 。

图片来自 Pixabay 的 Gerd Altmann

DevOps 的实践与云原生技术生态系统相结合，承诺将速度、一致性和效率注入到软件构建和发布的方式中。

DevOps 的一个副作用是模糊了开发和运维团队之间的界线，开发人员越来越多地承担起更多的运营责任。随着云原生部署的复杂性增加，市场上出现了众多云原生解决方案，从监控到容器安全和服务网格，开发人员在努力跟上所有这些新技术。

我们如何提高开发人员的生产力和体验？我们如何确保开发人员更多时间用于编写代码？平台工程可能会有答案，Gartner 将其定义为“构建和运营自助内部开发者平台（IDP），用于软件交付和生命周期管理的学科”。

许多客户正在加入平台工程的热潮，并建立平台团队。Puppet 的 2023 年平台工程报告显示，51% 的公司在过去三年内建立了平台团队。这些团队通常具有以下任务：

1. 识别其他功能的共享需求，并开发/利用集中管理的解决方案来解决这些需求。
2. 在集中管理的解决方案上提供治理和专业知识。
3. 使开发人员能够消费集中管理的解决方案，提供自动化和自助的方法，并提供必要的约束。这可以涉及利用更高级的界面，如开发者门户。

通过平台工程，开发人员可以从底层解决方案的复杂性中抽象出来。他们可以专注于编写由专业知识团队和自助界面支持的代码。这意味着平台团队可以拥有底层解决方案的运营和生命周期管理权。

Netflix 和 Adidas 等最初的采用者从他们的平台工程倡议中获得了显著的好处。

为什么？两者都准确地知道他们想要实现什么，并向后构建解决方案：Netflix 旨在统一他们的工程体验，而 Adidas 则希望缩短开发人员启动项目并将其集成到基础架构中所需的时间。

在我与亚太地区的客户交谈中，采用者通常有独特的原因。我最近与一个在许多国家分布的客户进行了交谈。对于他们来说，跨所有地区实现基础设施部署、应用开发和安全措施的一致性是首要任务。他们的解决方案是一个内部的云原生平台，可以被他们分布在各地的团队使用。另一个客户希望解放开发人员免于端到端的责任，例如管理基础设施，因此建立了一个基础平台团队，以便轻松地“插入”其他系统或应用程序。

从所有这些例子中可以明确看出，公司建立清晰的最终目标的重要性——无论是减少开发人员的责任还是创建一致的软件开发环境。随后可以采取快速简单的解决方案来实现这些目标。有三个关键教训可以遵循，以保持目标的视野：

• 采用“从大处着眼，从小处着手，逐步增长”的方法。从一个 MVP 或最小可行平台开始，它将改善开发者的指标或解决问题，例如开发者生产力。随着时间的推移，您可以为此 MVP 添加功能，或者您还可以创建另一个 MVP。并不一定要只有一个平台。
• 不要过于专注于工具。围绕平台工程的文献往往强调使用“专门的工具和平台”。尽管这可能很重要，但公司应该评估他们的目标，并确定使用最简单的可用工具最快地实现这些目标的方法。与一些供应商可能提议的情况不同，不是每家公司都会立即需要内部开发者门户或自助能力。解决方案可以很简单，例如拥有一个中央维基页面，记录开发人员需要的最常见的技术信息，以便他们不必花费很长时间搜索。这也可以是关于在 Visual Studio Code 编辑器上进行标准化，结合 Rancher Desktop，在本地开发机器上实现快速无摩擦的 Kubernetes 迭代。
• 实施有效的治理、最佳实践和技术专业知识来指导平台用户。这不仅有助于推动效率和一致性，还可以为用户设置保护措施。

平台工程不仅仅关乎工具链、内部开发者平台甚至 IT 或运维能力。在其核心，它是一门学科，可以在尽可能少的摩擦下增加开发者的生产时间，从构思阶段一直到交付阶段。

虽然平台工程并不能解决公司寻求的理想化、超级高效的开发人员体验和生产力提升问题，但如果逐步实施并得到治理和适当工具支持，它确实可以使您更接近这种理想状态。