OAM Open Application Model 是什么？OAM 为什么值得关注？一、应用组件Components二、应用部署配置文件Application Configuration三、应用运维特征Traits

OAM Open Application Model 是什么？OAM 为什么值得关注？一、应用组件Components二、应用部署配置文件Application Configuration三、应用运维特征Traits 介绍

Open Application Model 是什么？

Open Application Model
是一个用来构建云原生应用的规范。它描述了一个模型，开发人员可以在其中定义应用程序组件。应用程序操作员负责创建这些组件的实例并为它们分配应用程序配置。基础架构运营商负责定义、安装和维护平台上可用的基础服务。

OAM 是一个专注于描述应用的标准规范。有了这个规范，应用描述就可以彻底与基础设施部署和管理应用的细节分开。这种关注点分离（Seperation of
Conerns）的设计好处是非常明显的。举个例子，在实际生产环境中，无论是 Ingress、CNI 还是 Service
Mesh，这些表面看起来一致的运维概念，在不同的 Kubernetes 集群中可谓千差万别。
通过将应用定义与集群的运维能力分离，我们就可以让应用开发者更专注应用本身的价值点，而不是”应用部署在哪“这样的运维细节。

此外，关注点分离让平台架构师可以轻松地把平台运维能力封装成可被复用的组件，从而让应用开发者专注于将这些运维组件与代码进行集成，从而快速、轻松地构建可信赖的应用。Open
Application Model 的目标是让简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。

OAM 为什么值得关注？

关注点分离： 开发者关注应用本身，运维人员关注模块化运维能力，让应用管理变得更轻松、应用交付变得更可控。
平台无关与高可扩展 ：应用定义与平台层实现解耦，应用描述支持任意扩展和跨环境实现
模块化应用运维特征： 可以自由组合和支持模块化实现的运维特征描述

Kubernetes 项目作为容器编排领域的事实标准，成功推动了诸如阿里云 Kubernetes
（ACK）等云原生服务的迅速增长。但同时我们也关注到，Kubernetes 的核心 API 资源比如 Service、Deployment
等，实际上只是应用中的不同组成部分，并不能代表一个应用的全部。也许，我们可以通过像 Helm charts
这样的方式尝试表达一个可部署的应用，可一旦部署起来，实际运行的应用中却依旧缺乏以应用为中心的约束模型。这些问题都反映出，Kubernetes
以及云原生技术栈需要一种以应用为中心的 API 资源来提供一个专注于应用管理的、标准的、高度一致的模型，这个 API
资源可以代表完整运行的应用本身，而不仅仅是应用模板或者一个应用的几个组成部分，这就是今天阿里云与微软联合宣布推出开放应用模型 Open
Application Model （OAM）的原因。

一、应用组件（Components）

在 OAM
中，“应用”是由多个概念共同组合而成。第一个概念是：应用组件（Components），它是整个应用的重要组成部分。所以说，应用组件既可以包括应用运行所依赖的服务：比如
MySQL 数据库，也包括应用服务本身：比如拥有多个副本的 PHP
服务器。开发者可以把他们写的代码”打包“成一个应用组件，然后编写配置文件来描述该组件与其他服务之间的关系。应用组件的概念让平台架构师等能够将应用分解成成一个个可被复用的模块，这种模块化封装应用组成部分的思想，代表了一种构建安全、高可扩展性应用的最佳实践：通过一个完全分布式的架构模型，实现了应用组件描述和实现的解耦。

二、应用部署配置文件（Application Configuration）

为了将这些应用组件描述变成一个真正运行起来的应用，应用运维人员会通过一个专门的、包含了所有应用组件信息的部署配置文件来实例化这个待运行的应用。这个配置文件本身也是
OAM 规范中的一个声明式 API，用来让应用运维人员能够根据开发者或者平台提交的应用描述，实例化出对应的、真正运行起来的应用。

三、应用运维特征（Traits）

最后一个概念是一组应用运维特征（Traits），它们描述了应用在具体部署环境中的运维特征，比如应用的水平扩展的策略和 Ingress
规则，这些特征对于应用的运维来说非常重要，但它们在不同的部署环境里却往往有着截然不同的实现方式。举一个简单的例子，同样是
Ingress，它在公有云上和本地数据中心的实现可能完全不同：前者一般是 SLB 这样的云服务，而后者则可能是一个专门的硬件。这也就意味着针对这两个环境的
Ingress 运维工作，将会有天壤之别。但与此同时，无论是在哪个环境里，这个 Ingress
规则对于应用开发人员来说，可能是完全相同的。应用特征的设计，让这种关注点分离成为可能：只要这两个环境在 OAM 模型下提供了对 Ingress
这个应用运维特征的实现，那么应用就可以使用统一的 Ingress
规则描述，无差别地在这两个地方运行起来。与此同时，这两个环境的基础设施供应商可以继续通过配置这些应用特征的实现，来满足它们各自的运维要求（例如：不同环境里
Ingress 实现在满足合规性和安全性上的差异）。

OAM：平台无关、高可扩展的应用描述能力

与 PaaS 应用模型相比，OAM 有很多独有的特点，其中最重要一点是：平台无关性。虽然我们目前发布的 OAM 实现（rudr）是基于 Kubernetes
的，但 Open Application Model 与 Kubernetes 并没有强耦合。实际上，OAM
可以实现到任意平台或运行环境之上，这当然也包括边缘计算与物联网的场景。我们也认同 Kubernetes 在很多运行环境中可能并不是最好的选择，或者是像
Serverless 这类用户并不需要关心基础设施复杂性的运行环境。在这些场景下，OAM 都可以提供完全一致的应用管理体验。

第二个重要的特点是，OAM 的 specification （OAM 规范）在设计上天然是可扩展的。OAM 不像 PaaS
那样自成封闭体系，也不会通过某种独有的应用管理环境屏蔽掉底层平台的特点（比如：在 Kubernetes 之上”盖一个大帽子“）。相反，OAM
使平台层可以通过应用特征系统（Trait system）来体现平台的特性和差异性。也就是说，只要不同的平台都能够提供应用所需要的某些应用特征
(Trait)，开发人员就能轻松地研发跨平台的应用。类似地，哪怕最底层的硬件提供商，也可以通过应用特征系统来体现其平台特性。OAM
的整体设计，就是为了避免在平台可移植性中经常发生的“最小公分母”锁定问题。相反，OAM
不但提供了可移植性的能力，还确保了每个平台有能力去透出独有的特性和用途。OAM
让开发人员可以自由地针对不同平台以标准方式在可移植性和差异化功能之间取得平衡。

开放的社区与未来

如今，开放应用模型以及相应的 Kubernetes 实现有了初步成果，我们感到非常兴奋。 OAM 规范是基于 Open Web Foundation
协议进行开发的。我们的目标，从一开始就是让开放应用模型 Open Application Model
成为中立基金会的项目，以便实现开放治理与广泛合作。如果开发者希望了解更多信息，请前往开放应用模型项目的 GitHub 仓库： OAM
specification ，以及基于 Kubernetes 的 OAM
标准实现 Rudr 。

介绍内容来自
InfoQ