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

**原文**：[Here’s One Golden Path to Build an MVP Enterprise IDP](https://thenewstack.io/heres-one-golden-path-to-build-an-mvp-enterprise-idp/)

**作者**：[Charles Humble](https://thenewstack.io/author/charles-humble/)

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

最近不管参加什么技术会议，八成会看到一张看起来无所不能的[云原生全景图](https://cncf.io/?utm_content=inline-mention)，这张大图说明，现代软件开发的复杂度，已经让人略有不适了。

当然这张大图也显示了 Kubernetes 的成功，以及[云原生领域](https://thenewstack.io/cloud-native/)的创新，但是工具的[无序扩张](https://thenewstack.io/how-to-tackle-tool-sprawl-before-it-becomes-tool-hell/)，受影响的可不只是应用程序开发团队。

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

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

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

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

Kennedy 说：“在CNCF的环境下，无处不在的 [Kubernetes](https://thenewstack.io/kubernetes/) 结构是让一切变得更容易的原因之一；CNCF 上的所有东西都是以[云原生模式](https://thenewstack.io/what-are-cloud-native-patterns-and-how-should-you-use-them/)为基础构建的。而如果你所在的平台团队正在处理一些传统大型机，再加上一些云原生和其他一些东西，你的工具集可能是任何东西，并有一大堆不同的原则作为其核心。”

为了改善这种情况，Humanitec 发布了一系列[白皮书](https://humanitec.com/reference-architectures)和内部开发人员平台 (IDP) [参考架构的开源实现](https://github.com/humanitec-architecture)。这些内容结合在一起，为企业平台团队提供了一种方法，使其能够快速启动并运行新平台的[最小可行产品（MVP）版本](https://thenewstack.io/building-an-minimum-viable-product-a-founders-guide-to-success/)。参考架构本身基于麦肯锡的研究成果。

## 内部开发人员平台模式

在 6 月份的 [PlatformCon](https://platformcon.com/) 上，麦肯锡数字专家合伙人 [Stephan Schneider](https://www.linkedin.com/in/stephanschneider2/) 和该公司的高级 DevOps 工程师 [Mike Gatto](https://www.linkedin.com/in/mjgatto/) 发表了[演讲](https://www.youtube.com/watch?v=AimSwK8Mw-U)，介绍了他们如何根据对多个组织的分析，确定了一套内部开发者平台的通用模式。

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

如下图所示，麦肯锡建议的架构使用了许多现成的组件，包括开发人员门户构建工具 [Backstage](https://backstage.io/)、GitHub、Terraform 和 [Humanitec](https://humanitec.com/?utm_content=inline-mention) 的[平台编排器](https://humanitec.com/products/platform-orchestrator)，以及云提供商（本例中为 AWS）提供的组件。

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745897109079/ec1dd6f6-7a5b-4a15-963c-3874f5057025.png align="center")

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

* 开发人员控制平面：是开发人员发布代码并通过自己选择的界面访问平台的地方。它包括版本控制、集成开发人员环境、基础架构即代码和开发人员门户（如 Backstage）。除代码外，开发者还提供一个 [Score](https://score.dev/) 工作负载规范文件。这是一个 YAML 配置文件，指定了以与环境无关的方式运行应用程序所需的资源。
    
* 集成和交付平台获取应用程序代码，将其打包到一个或多个[容器](https://thenewstack.io/containers/)中，然后将其发布到亚马逊 ECR 等注册表中。一旦完成，CI 管道就会将注册表中的新工件通知平台协调器（麦肯锡使用 Humanitec 进行此操作），并启动构建。协调器会在部署前生成新的应用程序和基础架构配置文件和清单。
    
* 资源平面包括运行应用程序所需的资源。这可能包括计算（例如 Amazon EKS）；如果还没有 Kubernetes 集群，则构建 Kubernetes 集群；数据（例如 Amazon RDS、MySQL 等）；网络（例如 Amazon Route 53）；以及服务（例如 Amazon SQS）。
    
* 监控和日志记录交给云提供商，在我们的 AWS 示例中使用的是 Amazon Cloud Watch。
    
* 最后，安全管理机密和身份，以保护敏感信息（参考架构中使用了 [HashiCorp](https://www.hashicorp.com/?utm_content=inline-mention) [Vault](https://developer.hashicorp.com/vault)）。
    

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1745897091444/e661e9b2-9c57-45b1-b7b0-02b27716eb53.png align="center")

：

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

1. 读取：解释工作负载规格（也就是 Score 文件和上下文）。
    
2. 匹配：识别正确的配置基线以创建应用程序配置，并根据匹配的上下文识别需要解决或创建的资源。
    
3. 创建：创建应用程序配置；必要时创建（基础架构）资源；并获取证书，将用 Secret 的形式注入给应用程序。
    
4. 部署：将工作负载部署到与其依赖关系相连的目标环境中。
    

## IDP 的开源蓝图

麦肯锡的参考架构在 PlatformCon 上引起了很大反响，因此，受其启发，Humanitec 编写了几份[白皮书](https://humanitec.com/reference-architectures)，为构建内部开发人员平台提供参考架构蓝图，不仅有 AWS 版本，还有 Google Cloud Platform 和 [Microsoft Azure](https://news.microsoft.com/?utm_content=inline-mention) 的版本。

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

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

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

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

## 黄金之路，不是黄金囚笼

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

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

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

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

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

虽然各组织实施 IDP 的情况大不相同，但这一[参考架构](https://github.com/humanitec-architecture)可以作为一个有用的起点。