应用程序和基础设施之间的差距和新趋势

客座文章作者：Josh Gavant，Red Hat 应用平台解决方案架构师。博文最初发表在CNCF TAG 应用交付博客[1]上发布。

图片：https://www.cleo.com/blog/knowledge-base-cloud-integration-platform

TAG App Delivery 在 2021 年末成立了合作交付工作组，以收集和报告围绕基础设施功能和应用的协调交付的新兴趋势。TAG 指出，虽然基础设施团队正在成功地采用软件开发实践，并通过 GitOps 和 IaC（基础设施即代码，Infrastructure as Code）等工具不断地部署功能和修复，但基础设施功能的交付往往不能与使用该基础设施的应用程序的交付很好地协调。也就是说，应用程序和基础设施之间的交付存在差距，需要协调/合作来弥合这一差距。

该小组的主要目标是：a)确认存在差距的假设，b)阐明差距对最终用户的影响，以及 c)确定并鼓励新出现的趋势，以促进合作。例如，该小组的第一个假设[2]提到了以下现有趋势：

• GitOps：来自声明性描述符的配置的连续幂等协调
• Operators：面向协调的服务
• 流水线：服务和应用程序的强制性编排

在本文中，我们将回顾我们从最终用户和新兴CNCF 项目[3]（如 Backstage、Crossplane、Dapr、KubeVela 等）中了解到的新趋势。

在过去的一年中，我们还了解到，虽然基础设施和应用程序团队之间的“合作”是我们寻求实现的，但“合作交付（cooperative delivery）”对我们的大多数贡献者来说并不是一个熟悉的术语。认识到这种合作也是“内部开发人员平台”（IDP，internal developer platform）和新兴平台工程运动的目标，我们准备重新命名为平台工作组(Platforms WG)。

我们总是从用户和贡献者那里寻求更多的输入来指导我们。请考虑通过GitHub 表单[4]分享你的组织如何协调应用和基础设施交付，并在GitHub[5]或Slack[6]中分享你的想法。

平台工程

除了我们最初的假设之外，我们注意到协调基础设施和应用程序的一个新兴趋势是平台工程（PE，platform engineering），尤其是其自助服务能力的原则。例如，Backstage[7]是这些新兴平台的流行门户框架。根据 Humanitec 负责人Luca Galante[8]的说法，平台工程[9]是“设计和构建工具链和工作流的学科，能够在云原生时代为软件工程组织提供自助服务能力。”自助服务描述了合作交付的机制：开发人员通过遵循记录的步骤按需创建和使用其应用程序中的功能。

除了自助服务模式，平台工程还关注应用程序开发人员和运营人员——平台用户——的需求。这增加了 PE 对开发人员和其他平台用户的同理心，并帮助他们收集反馈，并迭代改进以满足他们的需求，就像产品开发人员为最终客户所做的那样。重心的转移也使平台开发更好地与企业的真正价值流保持一致，而不是让基础架构团队成为带外成本中心。这不完全是技术性的，平台工程和应用团队之间的同理心关系可以更好地协调基础设施功能和应用需求。

这些平台通常是使用基础的 CNCF 项目构建的，如 Kubernetes、Helm、Prometheus、Backstage、Istio、Knative、Keptn 等。

Kubernetes 的无处不在

我们在Crossplane[10]等项目中注意到的另一个趋势是采用 Kubernetes 资源模型来配置和管理所有类型的基础设施功能和应用程序组件。用户不再仅仅通过 Kubernetes API 提供部署、卷和入口；自定义资源定义（CRD，custom resource definition）现在可以创建数据库、身份、消息代理、可观测性系统等等。

GitOps[11]展示了应用程序持续协调的价值，有了如此多的可用资源类型，开发人员现在可以像应用程序一样协调基础架构。对于那些提供自己的基础设施功能的人来说，Operator Framework[12]是定制的基于 Kubernetes 的协调器实现的流行基础。

能力注入

最后，我们注意到像Dapr[13]和KubeVela[14]的项目，它们试图通过推理、后期解决（late resolution）和注入这些能力来协调应用的基础设施能力。这些项目通常要求应用程序开发人员声明他们需要的功能，如数据库和消息代理，然后在运行时解决实际的实现，可能使用边车容器或 eBPF 程序。像Istio[15]的一些项目甚至可以向应用程序开发人员透明地注入功能。

后期解决和注入放松了应用和基础设施的耦合，是另一种形式的“合作”交付。想象一下，根据应用程序的上下文，从不同的提供商那里获取数据库 AWS 中的 RDS 实例、GCP 的 CloudSQL 实例或本地的CloudNativePG[16]实例。

总结

合作交付工作组（即将成为平台工作组）的任务是收集反馈，并强调解决基础设施能力和应用协调差距的新兴趋势。加入[17]我们的 TAG 应用交付，推进这一主题以及其他与应用和平台开发人员和运营人员相关的主题。

参考资料

[1]

CNCF TAG 应用交付博客: https://cncf.github.io/tag-app-delivery/posts/cooperative-delivery-platforms

[2]

第一个假设: https://github.com/cncf/tag-app-delivery/blob/main/cooperative-delivery-wg/charter/README.md#examples-of-known-patterns-aimed-to-deploy-applications

[3]

CNCF 项目: https://landscape.cncf.io/card-mode?category=application-definition-image-build,continuous-integration-delivery&grouping=no

[4]

GitHub 表单: https://github.com/cncf/tag-app-delivery/issues/new/choose

[5]

GitHub: https://github.com/cncf/tag-app-delivery/discussions

[6]

Slack: https://cloud-native.slack.com/archives/CL3SL0CP5

[7]

Backstage: https://www.cncf.io/projects/backstage/

[8]

Luca Galante: https://platformengineering.org/authors/luca-galante

[9]

平台工程: https://platformengineering.org/blog/what-is-platform-engineering

[10]

Crossplane: https://www.cncf.io/projects/crossplane/

[11]

GitOps: https://www.cncf.io/projects/opengitops/

[12]

Operator Framework: https://www.cncf.io/projects/operator-framework/

[13]

Dapr: https://www.cncf.io/projects/dapr/

[14]

KubeVela: https://www.cncf.io/projects/kubevela/

[15]

Istio: https://www.redhat.com/en/blog/istio-service-mesh-applies-become-cncf-project

[16]

CloudNativePG: https://cloudnative-pg.io/

[17]

加入: https://github.com/cncf/tag-app-delivery