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

Kubernetes已成为行业领先的容器布局环境，极大地推动了Kubernes服务在全球主要公共云平台上的显著增长。然而，在库本内斯的核心资源中，如服务、部署等。从整个应用程序的角度来看，它似乎呈现了一种离散的应用程序状态。此外，尽管像赫尔姆图这样的对象看起来像是可部署的应用程序，但是它们缺少在实际部署后运行应用程序所需的应用程序中心模型。这需要一个清晰、完整和一致的模型来表达整个应用程序，而不仅仅是它的模板或组件。正因为如此，微软和阿里云在开放网络基础上合作推出了开放应用模型(OAM)。

项目地址:https://openappmodel.io OAM项目目前由两部分组成:规范和实现

什么是 Open Application Model？

OAM(开放应用模型)是一个专注于描述应用的标准规范。使用该规范，应用程序描述可以与基础架构部署和应用程序管理的细节完全分离。这种锥形分离的设计好处是非常明显的。例如，在实际生产环境中，无论是入口、CNI还是服务网格，这些看似一致的操作和维护概念在不同的库本内集群中可以说是非常不同的。通过将应用程序定义与集群的操作和维护能力分开，我们可以使应用程序开发人员更加关注应用程序本身的价值点，而不是操作和维护细节，例如“应用程序部署在哪里”。此外，关注点的分离允许平台架构师轻松地将平台的操作和维护能力打包到可重用的组件中，从而使应用程序开发人员能够专注于将这些操作和维护组件与代码集成在一起，从而快速而轻松地构建可信的应用程序。开放应用程序模型的目标是使简单的应用程序管理更加容易，复杂的应用程序交付更加可控。

一、应用组件（Components）

在OAM中，“应用程序”是几个概念的组合。第一个概念是应用程序组件，它们是整个应用程序的重要组件。因此，应用程序组件不仅可以包括运行应用程序的服务:例如MySQL数据库，还可以包括应用程序服务本身:例如具有多个副本的PHP服务器。开发人员可以将他们编写的代码“打包”到应用程序组件中，然后编写配置文件来描述组件和其他服务之间的关系。应用程序组件的概念使平台架构师能够将应用程序分解成可重用的模块。应用程序组件模块化封装的思想代表了构建安全和高度可伸缩应用程序的最佳实践:它通过完全分布式架构模型实现了应用程序组件描述和实现的分离。

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

为了将这些应用程序组件的描述转化为实际运行的应用程序，应用程序操作和维护人员将通过包含所有应用程序组件信息的特殊部署配置文件实例化要运行的应用程序。该配置文件本身也是OAM规范中的声明性应用编程接口，用于使应用操作和维护人员能够根据开发人员或平台提交的应用描述实例化相应的和真实运行的应用。

三、应用运维特征（Traits）

最后一个概念是一组应用程序操作和维护特性(Traits)，它描述了特定部署环境中应用程序的操作和维护特性，例如应用程序水平扩展策略和入口规则。这些特性对于应用程序的操作和维护非常重要，但是它们在不同的部署环境中通常有完全不同的实现方法。举个简单的例子，它也是入口。它在公共云上的实现可能与本地数据中心完全不同:前者通常是云服务，如SLB，而后者可能是专用硬件。这也意味着这两种环境的入口操作和维护工作将会有很大的不同。但是与此同时，无论在什么环境下，这个入口规则对于应用程序开发人员来说可能是完全相同的。应用程序特性的设计使得这种关注点的分离成为可能:只要这两个环境在OAM模型下提供应用程序操作和维护特性Ingress的实现，那么您的应用程序就可以使用统一的Ingress规则来无差别地描述和操作这两个地方。同时，这两种环境中的基础设施提供商可以通过配置这些应用特性的实现(例如，不同环境中入口实现的合规性和安全性的差异)

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

与PaaS应用模型相比，OAM具有许多独特的特性，其中最重要的一点是平台独立性。虽然我们已经发布的OAM实现(rudr)是基于库本涅斯的，但是在开放应用模型和库本涅斯之间没有强耦合。事实上，OAM可以在任何平台或操作环境上实现，当然也包括边缘计算和物联网的场景。我们也同意Kubernetes可能不是许多操作环境中的最佳选择，或者像无服务器这样的用户不需要关心基础架构的复杂性。在这些场景中，OAM可以提供完全一致的应用程序管理体验。

第二个重要特征是OAM规范在设计上是自然可扩展的。OAM不像PaaS那样是一个独立的系统，它也不会通过一些独特的应用程序管理环境来屏蔽底层平台的特性(例如在Kubernetes之上“构建一顶大帽子”)。相反，OAM通过应用特征系统使平台层能够反映平台的特征和差异。换句话说，只要不同的平台能够提供应用所需的一些应用特性(Trait)，开发者就可以轻松地开发跨平台的应用。同样，即使是最底层的硬件提供商也可以通过应用功能系统来体现其平台特性。OAM的总体设计是为了避免平台可移植性中经常出现的“最小公分母”锁定问题。相反，OAM不仅提供了可移植性，还确保了每个平台都能够展示独特的特性和用途。OAM为开发人员提供了在不同平台上以标准方式平衡可移植性和差异化功能的自由。

开放的社区与未来

今天，开放应用模型和相应的库本内实现已经取得初步成果，我们非常激动。OAM规范是基于开放网络基础协议开发的。我们的目标是使开放应用模型从一开始就成为一个中立的基础项目，从而实现开放治理和广泛合作。如果您想了解更多信息，请访问开放应用模型项目的GitHub仓库:OAM规范，并基于Kubernetes OAM标准实现Rudr。

今天的OAM项目只是向前迈出了一小步。我们期待收到您的反馈，并与您密切合作，为Kubernetes和任何云环境创建一个简单、可移植和可重用的应用模型。