欢迎光临
我们一直在努力

构建企业 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 的情况大不相同,但这一参考架构可以作为一个有用的起点。

文章来源于互联网:构建企业 IDP 最小可行性产品的黄金路径

赞(0)
未经允许不得转载:莱卡云 » 构建企业 IDP 最小可行性产品的黄金路径