微软与阿里云合作推出“开放应用模型(OAM)”

英文原文：Announcing the Open Application Model (OAM)

原文问题：微软与阿里云相助推出“开放应用模子（OAM）” 用于 Kubernetes 及更多平台的应用开拓、运行的开放尺度

Kubernetes 已经成为业界领先的容器编排情形，这极大地敦促了 Kubernetes 处事在环球各大首要公有云平台上的明显增添。可是，在 Kubernetes 的焦点资源中诸如处事、陈设等，从整个应用的角度来看，却像是泛起出应用的离散状态。另外，Helm chart 这样的工具，固然看起来像是可以陈设的应用，但真正陈设之后，却穷乏运行应用所需的应用中心模子。这就必要有一个界说清楚、完备同等的模子，来表达整个应用，而不只仅是它的模板大附崆组件。正是出于这样的思量，微软与阿里云基于 Open Web 基金会睁开相助，推出了开放应用模子（OAM）。

项目地点：https://openappmodel.io，OAM 项目今朝由类型和实现两部门构成

什么是 Open Application Model？

OAM (Open Application Model) 是一个专注于描写应用的尺度类型。有了这个类型，应用描写就可以彻底与基本办法陈设和打点应用的细节分隔。这种存眷点疏散（Seperation of Conerns）的计划甜头长短常明明的。 举个例子，在现实出产情形中，无论是 Ingress ， CNI，照旧 Service Mesh，这些外貌看起来同等的运维观念，在差异的 Kubernetes 集群中可谓千差万别。 通过将应用界说与集群的运维手段疏散，我们就可以让应用开拓者更专注于应用自己的代价点，而不是”应用陈设在哪“这样的运维细节。 另外，存眷点的疏散让平台架构师可以轻松地把平台的运维手段封装成可被复用的组件，从而让应用开拓者可以或许专注于将这些运维组件与代码举办集成，从而快速、轻松地构建可相信的应用。 Open Application Model 的方针是让简朴的应用打点变得越发轻松，让伟大的应用交付变得越发可控。

一、应用组件（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 。

本日 OAM 项目标宣布只是迈出的一小步。我们很是等候获得您的反馈，并与各人亲近协作，针对 Kubernetes 和恣意云情形打造一个简朴、可移植、可复用的应用模子。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!