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 NAPPTIVE platform supports launching and managing Applications that are defined using OAM standard as this reduces the complexity of working with low-level Kubernetes entities.
The Open Application Model adds a new Application level entity to Kubernetes. Up to this point, to deploy a cloud native application in Kubernetes, a user would need to deploy a set of YAML files containing the different entities (Deployments, Pods, Services, etc.) that are part of the application. The main issue with this approach is that once deployed, the concept of application is not longer available 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 more easily.
Moreover, by using OAM to represent applications, changes in deployment infrastructure such as moving from one cloud provider to another is no longer an issue since the translation of the Application to Kubernetes entities takes care of the subtle adaptations between different infrastructure providers.
Figure: An Application being translated into low-level Kubernetes entities
Several users can benefit from using the Open Application Model:
- Developers: Can focus on creating the individual components defining their parameters. This greatly improves reusability of components among applications, providing at the same time a clear documentation into how a component can be parametrized and adapted for a particular use case.
- Application operator: Focuses on deploying an application, making the required changes in terms of component parametrization, extensions using Traits, and deployment workflow. Having a top-level application entity makes easy to track component status and overall application state.
- DevOps: Can introduce custom extensions (traits, policies, workflow steps) so that they can be applied to all the organization.
The main elements of an OAM application are:
- Application: The top level entity that defines the components of an application, their parameters and associated extensions.
- Component: A Component represents a single microservice from the Application. The component definition defines the entities that will be generated in Kubernetes during rendering. For example, a webservice component will be translated as kubernetes Deployment and associated *Service. The component definition supports parametrization so that different aspects of the rendering process can be adapted to the specific use case. Notice that high-level components require a target image to be deployed, but custom components can have all that information already informed.
- Trait: A Trait represents an extension for an application component. This facilitates reusing components in different situations, and simplifies their packaging as the developer does not need to add any extra information for its deployment. 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).
The Open Application Model is evolving through the collaboration of the community. The NAPPTIVE platform currently supports OAM v0.3.1. If you require other version of OAM, contact support so we can add you to the first set of users that will test the new version.
Check the following links for more information on different aspects of OAM.
- Follow our Getting started guide to start using Napptive.