微软为 Kubernetes 等平台发布 Open Application Model

微软最近发布了Open Application Model（OAM），一个用于描述应用程序与其实现解耦（这样就可以清楚地分离关注点）的规范。OAM 的目标是 Kubernetes 和其他平台。

在实施 DevOps 时通常需要维护开发（dev）和部署（ops）之间的描述，帮助协调交付工作流，而 OAM 规范的目标就是要促进这一过程。OAM 的既定目标是“让简单的应用程序变简单，让复杂的应用程序易于管理”。Kubernetes 平台的最初实现叫作Rudr，它满足了上述的大部分目标。

下图（https://github.com/oam-dev/spec/#introduction）说明了不同的角色及其各自的职责，以及 OAM 规范的不同组成部分。

微软还发布了Dapr，一个开源的“可移植、基于事件驱动的运行时，开发人员可以很容易地构建可在云端运行的无状态和有状态微服务弹性应用程序”。Dapr 的目标受众是微服务开发人员，而 Rudr 的目标受众是运维人员。

InfoQ 采访了微软项目经理、规范负责人 Vaclav Turecek。

Turecek 谈到了基于 Kubernetes 的平台的快速增长，以及 OAM 如何区分开发人员和运维人员的职责，从而简化整个软件开发生命周期。他谈到了其他一些平台与 OAM 之间的重叠，以及 OAM 的独特性。最后，他介绍了 OAM 社区及其路发展线图。

InfoQ：OAM 解决了哪些问题？

Vaclav Turecek：当谈到应用程序的开发和部署时，我们认为区分开发人员和运维人员的职责是很重要的一点。如果这些角色混淆不清，就会导致沟通问题，出现 bug，甚至是服务中断。OAM 试图根据应用程序构建和基础设施运维的角色对应用程序进行建模，以此来解决这个问题。

具体地说，对于 Kubernetes，我们已经发布了一个叫作 Rudr 的参考实现。我们认为，OAM 有助于简化应用程序的组合和运维。Kubernetes 专注于容器基础设施，它的核心资源（如服务和部署）代表了应用程序的不同部分。它们不代表应用程序本身，而且实际上也并没有可用于表示整个应用程序及其运维的构造。OAM 为应用程序提供了某种构造，将应用程序及其运维特征（如自动伸缩、流量路由、摄入，等等）建模成一个整体。

InfoQ：OAM 在 Kubernetes 生态系统中有何独特之处？

Turecek：现如今，Kubernetes 拥有一个巨大的工具和库生态系统。在应用程序建模领域，我们还没有看到太多与 OAM 类似的东西。我们可以拿 Helm 和 CNAB 与 OAM 作一下对比，但这并不仅仅是因为 Helm 和 CNAB 的作者也是 OAM 的作者之一，还因为它们都涉及部署应用程序的某个方面。

Helm 和 CNAB 实际上是互补的，它们符合 Unix“把单个事情做到极致”的哲学，因为它们在这个领域解决了不同的问题，并且能够很好地协作。例如，你可以描述应用程序的组件以及如何使用 OAM 操作它，并将其直接部署到 Kubernetes 上。需要引入其他依赖项？将 OAM 定义和依赖项放入 Helm 的 chart 中，然后一起安装就可以了。需要在没有访问容器镜像权限的 Kubernetes 集群上运行？将 Helm chart 和容器镜像一起放入 CNAB 包中，然后一起安装就可以了。

OAM 还允许基础设施运维人员配置底层系统，底层操作系统可能提供了 OAM 应用程序可以访问的运维特性。这意味着你可以挂载各种现有的工具和库。例如，你可以挂载任何与 SMI 兼容的服务网格（如 Istio 或 Linkerd），获得负载均衡和流量路由功能。这样可以满足基础设施运维人员在不同环境下的独特需求，例如合规性或安全性，并为开发人员和应用程序运维人员提供一个良好的应用程序环境。

InfoQ：OAM 的目标包括多云吗？换句话说，它是否试图跨多个 K8s 云平台“标准化 YAML”？

Turecek：OAM 的主要思想是标准化应用程序的组合和运维模型，不管最终的运行环境是怎样的。因此，当你从一个平台转移到另一个平台，你将拥有一致的体验、一个可转移的过程和潜在的可移植性。也就是说，我们预想实现平台的功能会有所不同，模型就是围绕这个假设而设计的。这是 Kubernetes 之上的一个层，Kubernetes 只是一个支持平台。

InfoQ：OAM 规范是如何定义应用程序的，它与 Helm 有什么不同？

Turecek：经过研究我们发现，人们无法在微服务“应用程序”的定义上达成一致。目前，OAM 的设计并没有打算为微服务定义一个严格的“应用程序”结构。我们有应用程序范围的概念，可以将它看成是应用程序服务分组的边界。例如，将服务分在“健康”分组中，当升级其中一个服务时，我们会评估分组中每个服务的健康状况。这与 Helm 的 chart 不同，后者没有提供操作一组资源的功能。

InfoQ：是谁创建了 OAM？谁在维护？它的发展路线图是怎样的？

Turecek：OAM 是由 Helm、OpenKruise 和 Service Fabric 的作者开发的，目前微软和阿里巴巴的工程师在维护，他们遵循的是 Open Web Foundation 协议。我们的最终目标是将规范捐赠给基金会。

Kubernetes 平台的最初实现叫作 Rudr，可以在GitHub上找到。OAM规范提供了更详细的信息，包括不同的角色、各自的职责，等等。

原文链接：

Microsoft Announces Open Application Model for Kubernetes and Other Platforms