2019 年 10 月 17 日上午 9 点 15 分，阿里巴巴合伙人、阿里云智能基础产品事业部总经理蒋江伟在 QCon 上海《基于云架构的研发模式演进》主题演讲中，正式宣布：

“今天，我们同微软联合发布了一个全新的项目，叫做开放应用模型 Open Application Model（OAM）。”

项目主页：https://openappmodel.io

蒋江伟在发布中讲道：“OAM 这个项目是业界第一个云原生应用标准定义与架构模型。我们希望通过这样的架构模型，以高效、标准的方式连接应用开发者、运维人员和应用的最终用户，让这些云端应用的参与者能够享受到像智能手机上一样简单、轻松、畅快的应用管理体验。”

与此同一时间，微软杰出工程师（Distinguished Engineer） 、Kubernetes 项目创始人 Brendan Burns 也在微软的官方网站上，宣布了同阿里云的这次重量级联合发布。?

图片来源：https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-open-application-model/

你可能会好奇，到底什么是 OAM 呢？又是什么原因，让两家全球顶级技术公司走在一起，希望联合整个云原生技术社区共同推进这样一个应用定义与架构模型项目呢？

这个事情本身，可能要从世界上最早的一次云端应用交付的故事讲起。

一个云端应用交付的故事

2006 年 3 月 14 日，美国某在线电商公司发布了一个叫做 Simple Storage Service（简称 S3）的存储服务。在这个服务发布不久，一名来自微软的技术人员带着尝鲜的想法，编写了一个使用该服务作为底层存储的应用。据这位开发者讲述，从决定编写应用到将该应用交付运行“总共花掉了几天的时间”。对此，他感到非常兴奋，后来他在自己的博客里这么写到：

“这个服务的发布，彻底改变了技术行业的游戏规则”。

这位开发者的名字，叫做 James Hamilton?。他是 IBM DB2 早期的架构师，也是当时 Microsoft SQLServer 的负责人之一。就在编写完这个神奇的应用两年后，他选择加入了这家电商公司。如今，James Hamilton?已经成为了 AWS 的副总裁（VP）和标志性人物。

从 2006 年到现在，云计算经历了一波又一波变革和浪潮。如今的云，早已不再是 13 年前那个大众眼里需要“尝鲜”的陌生事物。如今的云服务，也早已在一次次的变革之中脱胎换骨，在成本和资源效率的极致优化中，将“摩尔定律”的失效推上了顶峰。2019 年 8 月，阿里云骄傲的向全世界宣布，云计算“拐点已至”。上云，正迅速成为企业进行应用架构和基础设施规划的默认选项。
?
在 2019 年，如果一位开发者要像 James 当年一样，把一个 Java Web 网站在云平台上线，到底体验如何呢？

云端应用管理的两大难题

在回答上面的问题之前，我们不妨先思考一下：现如今在智能手机上安装一个应用，是什么样的体验？升级应用呢？

在以 iPhone 为代表的智能手机上，应用管理的体验实际上是一个“如丝般顺滑”的感受。

现在，我们再回过头来看云。

一个云上的应用，肯定不只是简单的可执行文件。就拿 Java Web 网站为例，这个应用要想在云平台上被最终用户使用到，就需要有大量的外部依赖需要处理。这就是云端应用开发者实际上关心的事情，其实一点也不简单：

这种情况下，在云上交付一个应用的过程，实际上非常坎坷。

举几个例子：作为云上的开发者，我们首先需要花费大量的时间来进行应用整体部署架构的设计，才能大致搞清楚这个应用到底需要开通哪些云服务。但这依然避免不了一些让人头疼情况的发生，例如：

• 因为一个操作流程失误，一些需要预先申请的云资源不到位，就得返工重来；
• 一旦某个云服务的配置不合理，就得重新配置，甚至删掉重来；
• 整个上线应用的过程，我们需要不停地在各种云产品控制台之间来回跳转；
• 还有很多时候，我们不得不一个一个手工处理应用删除遗留下来的各种云资源。

上述情况的出现，总的来说是因为云上应用管理的过程，实际上是一个离散的状态，导致整个流程杂乱无序，也很难把控，出错返工就在所难免了。

再举个例子。除了过程上的繁杂之外，云端应用管理的另一个现状就是：开发者总是需要不停的去开通和配置各种各样的云服务，同时也要花大量的时间去开发各种云产品的开通和接入代码。尤其让人头疼的是，这些所有对云服务的开通、配置和接入工作，几乎都是“一次性工作”。我给一个应用组件做的事情，再上线另一个应用组件的时候，又得全部重新做一遍。甚至有时候为了接入一个新的云服务，必须重新开发整个应用。上述情况的出现，归根到底是因为对于应用所依赖的云服务来说，它们的开通与配置工作，并不是一个可复用的能力，这就导致了大量的重复劳动和对接工作需要一而再、再而三的在应用管理的过程中不断重复进行。

这些情况，都是现今制约和困扰着云端应用开发和运维人员的几个典型“症状”，也点明了当前云应用管理过程“耗时”、“耗力”背后，两个显著的症结所在：

1. 应用本身：不能以统一、自描述的方式定义应用与云资源的关系；
2. 云基础设施本身：没有一种统一、标准、高效的方式交付给应用使用。

智能手机 VS 云

在体验到了手机上 App 管理的流畅和简单之后，现在再来看云端应用管理的卡顿和繁杂，我们不禁会想到这样一个问题：云计算技术日新月异的今天，我们是否有机会在云上也感受到像智能手机一样的应用管理体验呢？

事实上，如果我们深入分析一下智能手机上的应用管理体系和如今的云端应用管理架构，就会发现，这两者本质上是完全一致的**。

首先，在标准的硬件，或者说手机的“标准化基础设施”之上，智能手机已经为使用者铺上了一个“标准化的接入层”。在 iPhone 上，这个标准化接入层，就是 iOS 操作系统，它对上暴露出 UNIX 风格的操作系统接口来屏蔽掉底层资源的细节。在云上，这一层实际上就是 Kubernetes 和云服务本身的 OpenAPI。
但，这显然还不是全部。
无论是应用开发者还是 APP 最终用户，我们还是不会直接跟 UNIX 操作系统接口打交道。这是因为，在“标准化的接入层”之上，iPhone 还为使用者提供了一整套的“标准化应用架构与管理体系”。这套体系，既包括了对操作系统接口的 Library 化封装（即：模块化的 SDK），也包括应用如何组织和打包的交付规范，还以此为基础，提供了 IDE 等一系列开发工具甚至编程语言。这才使得基于 iOS 之上的应用管理，呈现出了“如丝般顺滑”的用户体验。
这时候，我们再回过头来看云计算。就会发现：在对应“标准化的应用架构与管理体系”这一层，云的能力目前是缺失的。云上的应用，并没有一种统一和标准的方式来描述自己与云资源的关系，也没有一种统一和标准的方式来对接云计算的基础设施服务。
这也是为什么在 2006 年，一位开发者上线世界上最早的 S3 应用，只需要花费几天的时间，然而 13 年后，当云计算提供的能力已经强大到天壤之别的今天，我们在云上交付和升级一个 Java Web 网站，却恐怕还是要花费数小时之久，甚至更长。

什么是 OAM？

开放云应用模型 Open Application Model（OAM），它正是一个云原生时代的应用标准定义与架构模型。Open Application Model 的主要内容，就是为云端应用管理者提供了一套描述应用的规范。应用管理者只要遵守这个规范，就可以编写出一个自包含、自描述的“应用定义文件”。具体的说，这个应用定义文件实际上由两部分组成：

应用描述 = 应用组件 + 应用特征

应用组件：应用开发者通过一个声明式的描述，来定义他要部署和管理的是什么样的应用。比如，是 Java Web 网站？是容器？还是 Function？这个应用怎么运行，是通过 Kubernetes ？还是 ECS？需要注意的是，这个应用描述，是对应用本身开发和运行方式的、一个开发人员视角的叙述，它不会包括任何应用运维和基础设施相关的细节。

应用特征：应用运维人员则通过另一个声明式的描述，来定义这个应用的“运维特征”。比如，安全组策略怎么设置？路由访问策略是什么规则？水平扩展策略如何？可以看到，这些应用特征，实际上是对应用运维细节和基础设施能力的叙述。

所以说，在 OAM 规范下，在云上管理一个应用，实际上是通过这样两个声明式的描述配合来完成的。在实际操作中，应用开发人员只需要提交他所编写的应用描述，运维人员则负责定义和管理各种各样的应用特征。云平台或者应用架构师，则负责按照应用描述中的需求，为它绑定合适的应用特征。

而 OAM 这套规范的特殊性在于，它并不是一套“应用配置 + 外部依赖 ”的简单组合，而是在应用定义的规范中，“植入”了对云端应用管理至关重要的两个“解耦”：

• 第一，应用管理过程中的角色解耦。 通过这个解耦，OAM 应用管理流程中开发和运维角色就可以各司其职，只关注自己关心的部分，这是 OAM 提升开发者生产力的重要途径。而与此同时，云平台或应用架构师，则可以灵活的组合应用特征和应用描述，从而在完全不影响开发人员体验的情况下，为云上的应用搭配合适的应用特征。这种关注点分离（Seperate Conerns）的设计，使得 OAM 模型下的应用的定义，不仅职责明确，同时也能清晰的自描述出一个应用所依赖的所有云基础设施能力（即：特征），并为对它们的关系进行系统化管理提供了基础。

?

• 第二，应用定义与实现层解耦。通过这个解耦，用户的应用定义和云的基础设施能力是完全分开的。所以一个应用，不会再被局限于只能运行某种具体的平台或者云服务上：对于这些应用运行时的选择，只是应用描述中的一个可配置参数而已。而应用的运维特征，在实现层实际上就是每一个云基础设施能力的模块化实现。所以一旦一个应用描述与某个应用特征绑定，云平台就可以自动将对应的云服务接入到应用运行时当中，从而避免了用户陷入到“永无止境”的云服务开通和配置工作中。

不过，OAM 对于云端应用管理的价值，还远远不止更好的用户体验这么简单。

应用特征系统：平衡可移植性和差异性

在 Open Application Model 的模型中，应用管理人员可以灵活搭配应用描述与应用特征，从而对接不同的云基础设施能力到应用中。这种基础设施能力通过 OAM 对用户透出之后，实际上就能够差异化的表达不同运行环境能够为应用提供的不同基础设施能力。

举个例子，一位开发者定义了一个叫做“车”的应用描述，并做出了如下叙述：

• 要有安全性
• 要能有操控能力
• 要有行使动力

然后，他把这样的应用描述交给了云平台，云平台根据这个描述，为它绑定了一组比较基础的“应用特征”：

• 安全：安全带、气囊、普通刹车
• 操控：手动 5 档、普通方向盘
• 动力：普通发动机

这样，这个应用在它的最终用户看来，实际上就是一个“家用汽车”。

但是，过了一阵子，开发者决定对这个“车”进行一次升级。这时候，他该怎么做呢？

实际上，他什么也不用做。他只要告诉应用运维，为之前的“车”应用描述，绑定一组更加“强大”的应用特征即可，比如：

• 安全：高强度车架、悬挂减震、全身防护、赛车式刹车
• 操控：手动 8 档、赛车方向盘
• 动力：赛车引擎

所以，一旦上述“更强大”的应用特征，同“车”应用描述绑定，我们就可以将一个“家用车”立刻升级成一部强大的“赛车”。而在这个过程中，应用开发和应用运维唯一要做的事情，就是像“乐高积木”那样，灵活搭配和组装不同的应用特征而已。
?
而更重要的是，OAM 的设计初衷之一，是要提供标准化云端应用管理体验，这就需要“抹平”不同运行环境之间的不同，以便让应用“ 一次定义，多处运行”。但与此同时，OAM 提供的应用特征系统，则使得云平台标准化的暴露出自己的能力之后，用户依然可以通过对比不同运行环境的应用特征的差异，从而更准确的选择自己的应用要部署到哪个运行环境当中，真正意义上实现“Define Once, Run Where I Choose” 的交付体验。所以说，应用特征系统，正是 OAM 在设计中平衡可移植性和差异性的一个重要的创新之举。

OAM 项目的现状与未来

OAM 开源项目，主要包括了两部分内容：

1. Open Application Model Specification （OAM Spec）：这个项目是 OAM 模型的官方规范与标准库。在这个代码库中，详细的阐述和定义了 OAM 模型中的所有核心理念和详细到具体字段的 API 规范。与此同时，这些所有的 Spec 也都原生提供了进一步的扩展规范，使得这个模型本身具备了接入任意运行时、模块化任意云基础设施能力、标准化描述任意应用运维特征的、高灵活度的模型约束力。可以看到，这个库堪称 OAM 的使用者和实现者的官方“圣经”。

   OAM Spec 项目 GitHub 地址：https://github.com/oam-dev/spec

2. Rudr 项目: 这个项目，是 Open Application Model?在 Kubernetes 上的标准实现。Rudr 项目本身是 Kubernetes 的一个标准插件，只要安装上去即可为用户提供标准的 OAM 风格的的应用管理能力，通过模块化应用特征同 SMI，Knative，Istio 等应用基础设施能力无缝对接。值得一提的是，Rudr 项目是由 Rust 编写完成的，它的实现简洁、高效，性能优异，也是全世界第一个 Rust 实现的 Kubernetes 生态开源组件。

   Rudr 项目 GitHub 地址：https://github.com/oam-dev/rudr

虽然 OAM Spec 和 Rudr 项目目前是由阿里云和微软云的工程师共同发起和维护的，但这两个项目本身，均从一开始就采用中立基金会的方式进行运作，使用完全中立和开放的开源贡献者协议，同任何一家公司或者组织都没有绑定关系。这么做的原因也非常明朗：作为未来云计算应用管理生态的基础性模型，Open Application Model 从一开始就采用完全中立和开放的方式同整个社区协作，并计划在项目稳定后便移交给中立基金会进行托管。

目前，OAM 已经在阿里云多个项目中进行了数月的内部落地的尝试。通过一套统一、标准的应用定义体系，承载了多个云应用管理项目和产品的应用与外部资源关系的高效管理，并将云原生应用管理体验统一的带给了基于 Function、ECS、Kubernetes 等不同运行时的应用管理流程；通过应用特征系统，将多个阿里云独有的能力进行了模块化，大大提高了阿里云基础设施能力的交付效率。
与此同时，作为 OAM 的初创参与方，微软 Service Fabric 团队已经开始通过 OAM 模型将 Service Fabric 强大的应用基础设施能力进行了“乐高积木化”，从而无缝接入到云原生技术体系当中，并进一步在此基础上开始了“Mesh 化编程模型”的构建。

在未来的发展过程中，OAM 将会始终致力为云应用管理的参与者带来智能手机一般的使用体验，在保证可移植性和可扩展性的前提下，以标准化的方式帮助“应用”高效和高质量地交付到世界上任何一个位置。我们期待全世界每一位开发者和每一个云计算生态的参与者，都能加入到这个全新的应用架构模型的发展过程中来，共同打造一个繁荣的云端应用生态背后的标准模型和基础依赖。

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