Announcing the Open Application Model (OAM), an open standard for developing and operating applications on Kubernetes and other platforms

Kubernetes has become the leading container orchestration environment. Its success has driven the remarkable growth of Kubernetes services on every public cloud. However, the core resources in Kubernetes like Services and Deployments represent disparate pieces of an overall application. They do not represent the application itself. Likewise, objects like Helm charts represent a potentially deployable application, but once deployed there’s no application-centric model of the running application. This need to have a well-defined and coherent model that represents the complete application, not just its template and/or its constituent pieces, is why Microsoft and Alibaba Cloud have created the Open Application Model (OAM) project under the Open Web Foundation.

OAM is a specification for describing applications so that the application description is separated from the details of how the application is deployed onto and managed by the infrastructure. This separation of concerns is helpful for multiple reasons. In the real world, every Kubernetes cluster is different, from ingress to CNI to service mesh. Separating the application definition from the operational details of the cluster enables application developers to focus on the key elements of their application rather than the operational details of where it deploys. Furthermore, the separation of concerns also allows for platform architects to develop re-usable components and for application developers to focus on integrating those components with their code to quickly and easily build reliable applications. In all of this, the goal of the Open Application Model is to make simple applications easy and complex applications manageable.

In OAM, an Application is made from several concepts. The first is the Components that make up an application. These components might be services like a MySQL database or a replicated PHP server with a corresponding load balancer. Developers can author code that they package as a component and then author manifests that describe the relationships between that component and other microservices. Components enable platform architects and others to build re-usable modules which are known to encapsulate best practices around security and scalable deployment. They also enable the separation of the implementation of the component from the description of how those components come together in a complete distributed application architecture.

To transform these components into a concrete application, application operators use a configuration of these components to form a specific instance of an application that should be deployed. The configuration resource is what enables an application operator to run a real application out of the components provided by developers and platforms.

The final concept is a collection of Traits which describe the characteristics of the application environment including capabilities like auto-scaling and ingress which are important to the operation of applications but may be implemented in different ways in different environments. An easy example of such differences might be a hyperscale cloud-provided load balancer versus an on-premises hardware load-balancer. From an application developer’s perspective they are entirely identical, while from the operator’s perspective they are completely different. Traits enable this separation of concerns whereby the application can run anywhere its necessary traits are deployed. Those traits can then be configured by infrastructure operators to satisfy the unique operating requirements of their environment (e.g. compliance and security).

In contrast to a more traditional PaaS application model, OAM has some unique characteristics. Most importantly, it is platform agnostic. While our initial open implementation of OAM, named Rudr, is built on top of Kubernetes, the Open Application Model itself is not tightly bound to Kubernetes. It is possible to develop implementations for numerous other environments including small-device form factors, like edge deployments and elsewhere, where Kubernetes may not be the right choice. Or serverless environments where users don’t want or need the complexity of Kubernetes.

Equally important, the specification is extensible by design – rather than the walled garden of a PaaS, or an application environment that hides the unique characteristics of where it is running. Likewise, OAM enables platform providers to expose the unique characteristics of their platform through the trait system in a way that enables application developers to build cross-platform apps wherever the necessary traits are supported. Hardware providers can similarly expose the unique characteristics of their hardware platforms via traits. The entirety of OAM was designed to prevent the “lowest common denominator” problem that can occur in portable platforms. Instead OAM is designed to make portability possible while ensuring that each platform can still surface the capabilities that make them unique and useful. OAM provides developers the freedom to balance between portability and capability among platforms in a standard way.

We’re excited about the initial work we have done to develop this application-oriented open model and the implementation for Kubernetes. The specification is currently being developed under the Open Web Foundation agreement, and our goal is to bring the Open Application Model to a vendor-neutral foundation to enable open governance and collaboration. If you want to learn more, please have a look at the OAM specification, and Rudr – the open implementation for Kubernetes – over on Github. This is really just a start. We look forward to hearing your feedback and partnering closely to bring an easy, portable, and re-usable application model to Kubernetes and the cloud.

Questions or feedback? Please let us know in the comments.

OAM Project Leads

See more articles from this author