构建企业 Idp 最小可行性产品的黄金路径
原文：Here’s One Golden Path to Build an MVP Enterprise IDP
借助 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。
由于平台编排器在蓝图中起着核心作用，因此值得对其进行更详细的了解。下图描述了其核心功能
：
每一次 Git 推送，平台编排器就会解读工作负载运行所需的资源和配置，根据平台团队定义的规则创建应用程序和基础架构配置，并执行这些配置。Humanitec 用“读取、匹配、创建、部署”的执行模式来进行平台编排：
读取：解释工作负载规格（也就是 Score 文件和上下文）。
匹配：识别正确的配置基线以创建应用程序配置，并根据匹配的上下文识别需要解决或创建的资源。
创建：创建应用程序配置；必要时创建（基础架构）资源；并获取证书，将用 Secret 的形式注入给应用程序。
部署：将工作负载部署到与其依赖关系相连的目标环境中。
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 的情况大不相同，但这一参考架构可以作为一个有用的起点。