构建企业 IDP 最小可行性产品的黄金路径

原文：Here’s One Golden Path to Build an MVP Enterprise IDP

作者：Charles Humble

借助 Humanitec 最近发布的开源参考架构实施方案，企业平台团队可以快速创建内部开发人员平台。

最近不管参加什么技术会议，八成会看到一张看起来无所不能的云原生全景图，这张大图说明，现代软件开发的复杂度，已经让人略有不适了。

当然这张大图也显示了 Kubernetes 的成功，以及云原生领域的创新，但是工具的无序扩张，受影响的可不只是应用程序开发团队。

平台工程公司 Syntasso 的联合创始人兼首席运营官 Paula Kennedy 告诉 The New Stack：“我认为，平台团队和应用团队一样，都很难弄清楚自己的工具集应该是什么。”“因为平台工程作为是一种对实践的定义，因此其确定性更差，构成也更不清晰，所以在这方面，平台工程的问题也更大。”

除此之外，至少根据我个人的经验，起初，平台可能会自发形成。一个开发人员为自己构建一个工具，因为事实证明这个工具很有用，就分享给团队中的其他人。这种方法在初期是很有效的。但随着开发人员数量的增加，这种方法就会出现问题，因为正如 Kennedy 所说，“如果没有系统化思维的思维和主动的架构设计，那么就只能野蛮生长”。

到了一定程度，企业可能会发现这种方式不再适合自己，于是可能会寻求分拆出一个集中式的平台团队，试图以更完善的方式，让开发人员能够更快地入职，更快地交付。但是，应该如何开始组件平台团队呢？

显然，你需要与应用程序开发人员沟通，了解他们的需求和痛点，然后构建一个能解决这些问题的解决方案——可是解决方案如何选择合适的工具和组件呢？

Kennedy 说：“在CNCF的环境下，无处不在的 Kubernetes 结构是让一切变得更容易的原因之一；CNCF 上的所有东西都是以云原生模式为基础构建的。而如果你所在的平台团队正在处理一些传统大型机，再加上一些云原生和其他一些东西，你的工具集可能是任何东西，并有一大堆不同的原则作为其核心。”

为了改善这种情况，Humanitec 发布了一系列白皮书和内部开发人员平台 (IDP) 参考架构的开源实现。这些内容结合在一起，为企业平台团队提供了一种方法，使其能够快速启动并运行新平台的最小可行产品（MVP）版本。参考架构本身基于麦肯锡的研究成果。

内部开发人员平台模式

在 6 月份的 PlatformCon 上，麦肯锡数字专家合伙人 Stephan Schneider 和该公司的高级 DevOps 工程师 Mike Gatto 发表了演讲，介绍了他们如何根据对多个组织的分析，确定了一套内部开发者平台的通用模式。

麦肯锡就是麦肯锡，该报告的重点是面向企业而不是小型组织。在平台的背景下，这是说得通的，因为对平台的一种定义就是在企业规模上使 DevOps 实践发挥作用的一种尝试。

如下图所示，麦肯锡建议的架构使用了许多现成的组件，包括开发人员门户构建工具 Backstage、GitHub、Terraform 和 Humanitec 的平台编排器，以及云提供商（本例中为 AWS）提供的组件。

麦肯锡的蓝图将开发者平台分为五个平面，每个平面都有一套相关的能力，如上图白色方框所示的可观察性和网络化。

• 开发人员控制平面：是开发人员发布代码并通过自己选择的界面访问平台的地方。它包括版本控制、集成开发人员环境、基础架构即代码和开发人员门户（如 Backstage）。除代码外，开发者还提供一个 Score 工作负载规范文件。这是一个 YAML 配置文件，指定了以与环境无关的方式运行应用程序所需的资源。

• 集成和交付平台获取应用程序代码，将其打包到一个或多个容器中，然后将其发布到亚马逊 ECR 等注册表中。一旦完成，CI 管道就会将注册表中的新工件通知平台协调器（麦肯锡使用 Humanitec 进行此操作），并启动构建。协调器会在部署前生成新的应用程序和基础架构配置文件和清单。

• 资源平面包括运行应用程序所需的资源。这可能包括计算（例如 Amazon EKS）；如果还没有 Kubernetes 集群，则构建 Kubernetes 集群；数据（例如 Amazon RDS、MySQL 等）；网络（例如 Amazon Route 53）；以及服务（例如 Amazon SQS）。

• 监控和日志记录交给云提供商，在我们的 AWS 示例中使用的是 Amazon Cloud Watch。

• 最后，安全管理机密和身份，以保护敏感信息（参考架构中使用了 HashiCorp Vault）。

由于平台编排器在蓝图中起着核心作用，因此值得对其进行更详细的了解。下图描述了其核心功能：

每一次 Git 推送，平台编排器就会解读工作负载运行所需的资源和配置，根据平台团队定义的规则创建应用程序和基础架构配置，并执行这些配置。Humanitec 用“读取、匹配、创建、部署”的执行模式来进行平台编排：

1. 读取：解释工作负载规格（也就是 Score 文件和上下文）。

2. 匹配：识别正确的配置基线以创建应用程序配置，并根据匹配的上下文识别需要解决或创建的资源。

3. 创建：创建应用程序配置；必要时创建（基础架构）资源；并获取证书，将用 Secret 的形式注入给应用程序。

4. 部署：将工作负载部署到与其依赖关系相连的目标环境中。

IDP 的开源蓝图

麦肯锡的参考架构在 PlatformCon 上引起了很大反响，因此，受其启发，Humanitec 编写了几份白皮书，为构建内部开发人员平台提供参考架构蓝图，不仅有 AWS 版本，还有 Google Cloud Platform 和 Microsoft Azure 的版本。

麦肯锡的参考架构引起了很大反响，因此，受其启发，Humanitec 发布了参考架构开源实施系列的第一个版本，由一组 Terraform 配置组成，能够在 AWS 和 GCP 上部署蓝图示例。AWS 版本包括 Backstage（如上图所示），并计划逐步增加 Azure 和多云实施的示例。

这为平台团队提供了一种方法，可以快速为内部开发人员平台开发出企业级最小可行产品（MVP），同时也为 Humanitec 平台编排器的试运行提供了便利。

Humanitec 产品经理 Luca Galante告诉 The New Stack：“社区对参考架构的反响令人难以置信。”我们在前几周就有了 1 万次下载，这充分说明了业界对清晰蓝图和设计模式的需求。

当然，您也可以随意更换组件，包括 Humanitec 本身。回想一下图中的平面和功能，“平面很重要，因为它们提供了方向并奠定了基础，而功能也很重要”Humanitec 的平台架构师 Clemens Jütte 告诉 The New Stack。“你肯定希望拥有图上的所有功能，我们从未见过没有这些功能的平台。但方框内的标识并不重要。你可以挑挑拣拣，开始迭代，建立你想要的 IDP。

黄金之路，不是黄金囚笼

企业面临的另一个挑战是，他们很可能已经有了一些不愿放弃的流程和工具，而且不同的团队有不同的需求。因此，灵活性也是很重要的

同样，强迫开发人员使用某个特定的平台也是不明智的–某个特定的团队或小组可能有充分的理由，在既定路线之外做事情。如果强制性的工具阻碍了开发人员完成他们的工作，也会出现影子 IT 实践。更好的做法是，尽可能让平台对应用程序开发人员具有吸引力，这样他们在任何情况下都会优先选择适合自己的平台。

加拿大金融公司 Nesto 的 DevOps 总监 Mathieu Frenette说，“我们谈论的是黄金路径，而不是黄金牢笼” 而 Kennedy 说：“我非常喜欢这种说法，因为这有助于我思考这样一个事实，即开发人员需要有一条简单的道路；他们需要有一个模板，帮助他们快速上手，但他们也还保有打破他的权利。”

“平台团队需要能够通过抽象提供简单性，同时在需要时提供灵活性。”

Galante 认为，“目前还没有一个平台能够保留我的 Terraform 设置，保留我的基础设施和 CI 管道，但我可以以一种更强大的方式将它们粘合在一起，从而获得内部开发者平台所承诺的所有好处。”

虽然各组织实施 IDP 的情况大不相同，但这一参考架构可以作为一个有用的起点。