像智能手机同样管理云端应用：阿里云联合微软全球首发开放应用模型（OAM）

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

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

项目主页：openappmodel.io

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

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

图片来源：cloudblogs.microsoft.com/opensource/…

你可能会好奇，到底什么是 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. 应用自己：不能以统1、自描述的方式定义应用与云资源的关系；
2. 云基础设施自己：没有一种统1、标准、高效的方式交付给应用使用。

智能手机 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 地址：github.com/oam-dev/spe…

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

Rudr 项目 GitHub 地址：github.com/oam-dev/rud…

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

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

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

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