Link Search Menu Expand Document

Open Application Model (OAM)

The Open Application Model (OAM) is an application-centric specification that is cloud provider agnostic. This greatly improves the reusability of components and reduces the friction of moving applications in multi-cloud environments. The specification is based on defining a clear set of user personas and roles, and creating entities that match the expectation of each of them.

What is OAM?

The Open Application Model adds a new “application” level entity to Kubernetes. Up to this point, to deploy a cloud native application in Kubernetes, the user will deploy a set of YAML files containing the different entities that are part of the application. The main issue with this approach is that once deployed, the concept of application is not longer availble in Kubernetes. If we want to check the status of the deployments associated with an application, either we use the labels/annotations approach to filter those, or there is not such an entity that logically groups them. With OAM we add a new application entity that will enable reasoning about its components.

Who can benefit from OAM?

Several users can benefit from using the Open Application Model

  • Developer: Can focus on creating the individual components and setting high-level requirements such as “this component should have an endpoint exposed”. How that requirement is satisfied in a particular cloud provider is outside of their responsibilities.
  • Application Operator: Focuses on the deployment of an application, applying the required parameters. Having a top-level application entity makes easy to track component status and overall application state.
  • Infrastructure Operator: Focuses on creating a platform that can execute OAM applications, having the capability of adding/configuring new extensions that facilitate satisfying high-level requirements such as how certificates will be generated.

Anatomy of an OAM application

The main elements of an OAM application are:

  • Component: A component defines a single service inside the application. Typically you will associated each service with a container, which in the kubernetes world is usually expresed as a Deployment. Components can define a set of parameters so that the same component definition can be reused in multiple applications.
  • Trait: A trait is a mechanism that extends the functionality of a component. Depending on the trait itself, this could map to sidecars in the kubernetes layer (e.g., trait to redirect logs), or could create other entities (e.g., an ingress trait may create an ingress/loadbalancer).
  • Application: Defined as ApplicationConfiguration this entity contains the components that form the application and it is the place to set the parameters and apply extensions to the components in the form of traits.

For example, considering the napptive/wordpress-mysql:5.7.0 application available on the catalog, the OAM representation would look like:

Wordpress in OAM

In this case, the application my-wordpress is composed of two components: mysql-db and wordpress. A set of parameters are defined for both of them related to default password and port number. Notice that the parameters are defined on those elements to illustrate how they can be used. In general, setting password in clear is not recommended. On the wordpress component we attach a trait that will be in charge of exposing the web to the outside world. In NAPPTIVE this translates in creating a ingress with a TLS certificate.

Both component are also part of a Scope which is similar in behavior to the Trait one, but applies to multiple components. In this case, as an example, we define a health scope for both components which can give us a finer granularity about the state. Other uses of scopes are related to security context, placement, etc.

Take a look to the Deploy an OAM application guide to discover how those entities look like.

About OAM versions

The Open Application Model is evolving through the collaboration of the community. We currently support OAM v0.2.1, but we are actively testing support for OAM v0.3.0 that has just being released in May 2021. If you require the latest version of OAM, contact us so we can add you to the first set of users that will test the new version.

What changes can I expect in the new version? The overall concepts have not changed in the v0.3.0, however some entities has been renamed (e.g., ApplicationConfiguration becomes Application). Once we have added v0.3.0 to the platform, we will include some guidelines into migrating applications.

References

Check the following links for more information on different aspects of OAM.

What’s next