微软最近宣布 创建一个开源项目，这是 OAM，你在Kubernetes上开发和运行应用程序的新标准 和其他平台。 之所以启动这个新项目，是因为Kubernetes已成为首要的容器编排环境。
它的成功导致了所有公共云中服务的显着增长。 但是，我Kubernetes的核心资源， 作为服务和实现，它们代表了全局应用程序的不同元素。 它们不代表应用程序本身。 类似地，诸如Helm图表之类的对象表示潜在的可部署应用程序，但是一旦实现，就没有模型关注当前应用程序。
这就是Microsoft和阿里云创建开放应用程序模型项目的原因 （OAM）在Open Web Foundation下。
OAM 是描述应用程序的规范 以便将应用程序的描述与 基础架构如何实现和管理应用程序。 出于几个原因，这种关注分离是有用的。
在现实世界中，从入口到容器网络接口（CNI）到服务网格，每个Kubernetes集群都是不同的。
通过分开定义 集群运作细节的实施情况， 应用程序开发人员可以专注于关键要素 而不是实施的操作细节。
此外，关注点的分离还使平台设计师可以开发可重用的组件，并使应用程序开发人员可以专注于将这些组件集成到其代码中，从而快速轻松地构建可靠的应用程序。
在这一切中 开放应用程序模型的目标是使简单的应用程序变得容易 而且复杂的应用程序是可管理的。
在OAM中，一个应用程序包含几个概念。 第一个是组成应用程序的组件。 这些组件可以是服务，例如MySQL数据库或具有相应负载平衡器的复制的PHP服务器。
开发人员可以创建将其打包为组件的代码， 然后作者声明他描述了该组件与其他微服务之间的关系。 这些组件使平台架构师和其他人员可以创建可重用的模块，这些模块可以封装安全性和可扩展部署中的最佳实践。
它们还允许您分离组件实现 这些组件如何组合成一个
为了将这些组件转换为具体的应用程序，应用程序操作员使用这些组件的配置来形成要部署的应用程序的特定实例。
配置工具允许应用程序操作员从开发人员和平台提供的组件中运行真实的应用程序。
最终概念是一组描述应用程序环境特征的功能，包括对应用程序的操作很重要的自动缩放和输入等功能，但可以在不同环境中以不同方式实现。
这种差异的一个简单示例可能是超大规模负载均衡器 提供的云 与本地硬件负载平衡器.
从应用程序开发人员的角度来看，它们是完全相同的，而从操作人员的角度来看，它们是完全不同的。 功能可实现问题的这种分离，以便应用程序可以在部署其所需功能的位置运行。
然后，基础架构运营商可以配置这些功能，以满足其环境的独特运营要求（例如合规性和安全性）。
与更传统的PaaS应用程序模型不同，OAM具有独特的特性。 更重要的是，他是一个与平台无关的人。 微软指出，尽管最初的OAM（称为Rudr）是基于Kubernetes的，但OAM本身与Kubernetes并没有密切的关系。
可以为许多其他环境开发实现， 即使对于与小型设备相关的格式，Kubernetes也不是正确的选择。 我们还需要考虑用户不需要或不需要Kubernetes的复杂性的无服务器环境。