Open Application Model is a specification for building cloud native applications.

Focused on separating concerns of development and operation needs, Open Application Model brings modular, extensible, and portable design to building and delivering applications on platforms like Kubernetes.

This repository is unstable, and open to contributions. The specification is under development, and breaking changes could be made. Interested in contributing? Take a look at the issue queue! We're looking for more great ideas on how to model cloud native applications.

When it comes to application development and deployment, we think it is important to distinguish between the parts that developers are responsible for, and the parts that operations is responsible for. Otherwise, if these roles get muddled, it would result in communications mishaps, bugs, or even service outages.

Open Application Model attempts to solve this problem by modeling the application according to the roles responsible for building and running apps and operating infrastructure.

• Developers are responsible for describing what a microservice or component does, and how it can be configured. They are the domain experts on the code.
• Application Operators are responsible for configuring the runtime aspects of one or more of these microservices. They are the domain experts on the platform.
• Infrastructure Operators are responsible for setting up and maintaining the infrastructure within which applications run. They are the domain experts on the low-level details.

For more details and user stories, see introduction.md.

Rudr is a reference implementation of the Open Application Model specification for Kubernetes. To get started with an example on the Open Application Model, go to the Rudr Tutorial guide.

Notational Conventions

1. Purpose and Goals
2. Overview and Terminology
3. Workload Types
4. The Component Model
5. Application Scopes
6. Traits
7. Application Configuration
8. Practical Considerations
9. Design Principles

To get an overview of the milestones and their description please visit the Milestones page.

Triaging of items into milestones will occur during the bi-weekly community call. During this call, issues might be brought into milestones, removed from milestones or moved between milestones.

See the CONTRIBUTING guide for more information about submitting changes to the spec.

One of the easiest ways to contribute is to participate in discussions. There are several ways to get involved.

Come find community blogs and conference talks about OAM in community/talks_and_blogs.md.