The Open Application Model defines a standard, platform-agnostic way to describe cloud and edge applications. The goal of the specification is to provide a common way to describe applications agnostic to any specific container runtime, orchestration software, cloud provider, or hardware configuration, with clearly defined roles for developers and operators, while still allowing implementations to make use of the native APIs, tools, and features that are unique to the implementation and its underlying platform.
The central problem this specification seeks to address is how distributed applications can be composed and handed off to those responsible for operating them. The problem is not so much about how to write programs, but how to take components of a service-oriented (or microservice-oriented) architecture, and streamline the workflow that surrounds such applications.
For example, a contemporary cloud application may be composed of dozens of microservices, each responsible for a discrete chunk of what, broadly speaking, is "an application." Such applications need to be configured, deployed, audited, updated, and deleted. Sometimes the application must be treated as a whole, and sometimes finer levels of granularity are required. And most importantly, often such applications are managed not by one person or one team, but by multiple teams who must cooperate to achieve reliability, stability, and timeliness.
This specification provides a description of such applications, where the description is aimed at separating the concerns of developers from the concerns of operators. Furthermore, it suggests patterns and processes for managing such applications. The specification describes a model for cloud native (i.e., highly distributed) applications, encompassing public cloud technologies, on-prem solutions, and IoT/edge technologies. By specifying a common model, this specification provides a foundation for multiple implementations of a shared description of cloud native applications.
Additional goals of the specification are to:
- Define roles and responsibilities with respect to the component and application models.
- Promote the genesis of multiple, differentiated implementations of both tooling and runtimes which can operate on a common class of components and applications.
Non-goals include:
- Defining or prescribing specific development or operational workflows.
- Defining the schemas of operational resources, for example (but not limited
to):
- Secrets (secure, encrypted values)
- Networks
- Volumes
- Describing or defining the runtimes themselves.
| Next Part |
|---|
| 2. Overview and Terminology |