微软推开放应用程式模型以规範云端原生应用程式建置

微软与阿里云合作，于开放网页基金会下开源了OAM（Open Application Model）专案，这是在Kubernetes上建置云端原生应用程式的规範，用来定义完整代表应用程式的模型，与传统PaaS应用程式模型最大的差异在于，OAM独立于平台，可同时保持标準以及各平台的独特性，还可在非Kubernetes环境开发实作。

Kubernetes目前已经成为主流容器调度工具，各公有云平台大量地推出Kubernetes服务，但是微软提到，Kubernetes的核心资源，像是服务（Services）或是部署（Deployments）等各代表了整个应用程式的不同部分，而像是Helm Charts物件，代表了潜在可部署的应用程式，但是一旦部署完成，便没有一个以应用程式为中心的模型，来定义执行中的应用程式，微软认为，目前需要一个定义完整且一致的模型，来代表整个应用程式。

而OAM则是可以用来描述应用程式的规範，以便将应用程式描述从应用程式部署细节和託管基础架构中分离。微软提到，这样的分离有多种好处，由于每个Kubernetes丛集都是不同的，从丛集运作细节分离应用程式定义，可使开发者更关注应用程式的关键元素，而非部署的运作细节。另一个分离的好处，便是允许平台架构师重複使用元件，并让应用程式开发者专注于将元件和程式码整合在一起，以便更快速简单地建置高可靠性应用程式。

在OAM中，应用程式由多个概念组成，第一是应用程式的元件，像是MySQL资料库，开发人员也可以将自己的程式码打包成元件，并且编写Manifests描述元件与微服务之间的关係，这些元件成为平台架构师可以重複使用的模组，模组中封装了安全性和可扩展性部署的最佳实践。

第二个概念则是配置档案，应用程式营运人员可利用元件配置档案，来实际部署应用程式的实例，微软解释，这些配置资源可以让营运人员真正执行应用程式。最后一个重要概念则是Traits集合，用来描述应用程式环境的特徵，包括自动扩展以及Kubernetes Ingress等。

微软提到，比起传统的PaaS应用程式模型，OAM最重要的差异是与平台无关，虽然最初的OAM实作Rudr是建立在Kubernetes之上，但事实上OAM并没有与Kubernetes紧密绑定，因此在不同的环境像是小型装置或是边缘装置的部署等，可以发展成不同的实作，或是在无伺服器的环境，用户根本不需要了解Kubernetes的複杂性。

OAM还具有可扩充性，可让平台供应商透过Trait系统提供用户平台特别的功能，硬体厂商也可以透过类似的方法，以Trait系统提供硬体平台的特别功能，OAM的设计让应用程式拥有高可移植性，但是每个平台又都能提供特别的功能，供开发人员在标準以及功能间自己取得平衡。

OAM根据开放网页基金会协定开发，微软提到，他们的目的就是要让OAM发展成为供应商中立的规範，以实现开放治理和社群协作。目前OAM的开放Kubernetes实作Rudr已经在GitHub上开源。