重磅发布 | 全球首个云原生应用标准定义与架构模型 OAM 正式开源

做者： OAM 项目负责人

导读：2019 年 10 月 17 日，阿里巴巴合伙人、阿里云智能基础产品事业部总经理蒋江伟（花名：小邪）在 Qcon 上海重磅宣布，阿里云与微软联合推出开放应用模型 Open Application Model （OAM）开源项目。OAM的愿景是以标准化的方式沟通和链接应用开发者、运维人员、应用基础设施，让云原生应用管理与交付变得更加简洁，高效，而且可控。

OAM 为何值得关注？

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

Kubernetes 项目做为容器编排领域的事实标准， 成功推进了诸如阿里云 Kubernetes （ACK）等云原生服务的迅速增加。但同时咱们也关注到，Kubernetes 的核心 API 资源好比 Service、Deployment 等，实际上只是应用中的不一样组成部分，并不能表明一个应用的所有。也许咱们能够经过像 Helm charts 这样的方式来尝试表达一个可部署的应用，可一旦部署起来，实际运行的应用中却依旧缺少以应用为中心的约束模型。这些问题都反映出，Kubernetes 以及云原生技术栈须要一种以应用为中心的 API 资源来提供一个专一于应用管理的、标准的、高度一致的模型，这个 API 资源能够表明完整运行的应用自己，而不只仅是应用模板或者一个应用的几个组成部分，这就是今天阿里云与微软联合宣布推出开放应用模型 Open Application Model （OAM）的缘由。 项目地址：https://openappmodel.io

OAM 项目目前由规范和实现两部分组成

什么是 Open Application Model？

OAM 是一个专一于描述应用的标准规范。有了这个规范，应用描述就能够完全与基础设施部署和管理应用的细节分开。这种关注点分离（Seperation of Conerns）的设计好处是很是明显的。 举个例子，在实际生产环境中，不管是 Ingress ，CNI，仍是 Service Mesh，这些表面看起来一致的运维概念，在不一样的 Kubernetes 集群中可谓千差万别。 经过将应用定义与集群的运维能力分离，咱们就可让应用开发者更专一于应用自己的价值点，而不是”应用部署在哪“这样的运维细节。 此外，关注点的分离让平台架构师能够轻松地把平台的运维能力封装成可被复用的组件，从而让应用开发者可以专一于将这些运维组件与代码进行集成，从而快速、轻松地构建可信赖的应用。 Open Application Model 的目标是让简单的应用管理变得更加轻松，让复杂的应用交付变得更加可控。

1、应用组件（Components）

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

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

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

3、应用运维特征（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 。

今天 OAM 项目的发布只是迈出的一小步。咱们很是期待获得您的反馈，并与你们密切协做，针对 Kubernetes 和任意云环境打造一个简单、可移植、可复用的应用模型。

点击阅读原文直达OAM主页：https://openappmodel.io

“ 阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术公众号。”