This doc gives an introduction of the Open Application Model in a story-based format. Its goal is to help end users and developers quickly understand and implement the specification.
In the following, we go through a story that describes an application delivery lifecycle. The storyline looks like this:
- The developer creates a web application;
- The application operator deploys instances of that application, and configures it with operational traits, such as autoscaling;
- The infrastructure operator decides which underlying technology is used to handle the deployment and operations.
The story begins with the application developers who create an application, such as an online shopping application. They know how to write and test the code. The program takes a few parameters such as log level and HTTP port. To let the developers focus on implementing the application's business logic, application operators (either human or automated operation platforms) take care of operational tasks. This provides a "serverless" experience to the developers. The developers only need to develop and package the application, and then deliver it to the application operators.
To deliver their application, the developers define ComponentSchematic YAML files. In the Open Application Model, each individual component of a program is described as a ComponentSchematic YAML by the application developer. This file encapsulates a workload and the information needed to run it. For example, it can contain the container image packaging the program, whether it needs an endpoint, if its designed to run as a task to completion or as a server, environment variables, and any parameters the developers want to expose to an operator to override at deployment time.
The following diagram demonstrates this workflow:
To run and operate an application, the application operator sets parameter values for the developers' components and applies operational characteristics, such as replica size, autoscaling policy, ingress points, and traffic routing rules in an ApplicationConfiguration yaml. In OAM, these operational characteristics are called traits. Writing and deploying a ApplicationConfiguration yaml is equivalent to deploying an application. The underlying platform will create live instances of ComponentSchematic and attach operational traits to them according to the ApplicationConfiguration spec.
The following diagram demonstrates the workflow:
The application developer and application operator have so far described an application and its operational characteristics in platform-neutral terms. The power of the Open Application Model comes from the underlying platforms that implements the model, which can surface the capabilities that make the underlying platforms unique and useful through OAM in a way that is consistent across any platform that supports the model.
Infrastructure operators are responsible for declaring, installing, and maintaining the underlying services that are available on the platform. For example, an infrastructure operator might choose a specific load balancer technology when deploying to a cloud provider to expose the service.
The following diagram demonstrates the platform architecture:
Focused on the separation of development concerns from operational considerations through a platform-agnostic specification, the Open Application Model brings modular, extensible, and portable design to building and delivering applications on platforms like Kubernetes.
With OAM, platform builders can provide reusable modules in the format of Components, Traits, and Scopes. This allows platforms to do things like package them in predefined application profiles. Users choose how to run their applications by selecting profiles, for example, microservice apps with high SLO requirements, stateful apps with persistent volumes, or event driven functions with horizontally autoscaling. This brings a serverless experience to end users in a cloud native way, all due to the modular design.
Another benefit for end users is having portable apps across platforms. If an app can be deployed and used on one provider, it should be able to run on any other providers. We define must-implement, recommended, and candidate types in core, standard, and extended APIs. This will ensure portability and provide extensibility in the same spec. Of course, not everything is portable and the primary concern of such an interface is that it is a "lowest-common denominator". Our aspiration is to build a vendor-neutral, community-owned spec and the most popular APIs will be embraced and added to the specification over time. In this way, the evolution will ensure that most users will be successful in building cloud native applications via the Open Application Model.