Open Application Model Specification

What is NEW!
May 18th, 2020. Crossplane becomes the standard Kubernetes implementation of OAM spec!
Mar 27th, 2020. OAM v1.0.0-alpha.2 is RELEASED! The new spec is highly extensible and native to Kubernetes runtime. Check the spec and What's new in OAM v1alpha2 for more detail!
Mar 26th, 2020. A proof-of-concept project named AWS ECS for OAM is published! Check the AWS Labs repo and have fun with developer centric experience with OAM + Fargate!

Open Application Model is a platform-agnostic 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 different platforms.

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

Introduction

Open Application Model provides a standard and extensible framework for platform builders to create application centric platforms on top of lower level runtime systems such as Kubernetes with additions of discoverability, manageability and interoperability.

Open Application Model empowers application platforms to provide standardized application centric primitives (e.g. Workloads and Traits) instead of exposing infrastructure details to end users, while retaining the extensibility of the underlying runtime system. With the idea of simplify creating upper layer platforms, the model won't lock you into specific abstractions -- on the contrary, its primitives allow you to define the right level of abstraction depend on your own use case.

A team-centric model

When it comes to the application centric primitives, we think it is important to distinguish between the parts that developers are responsible for, and the parts that operators (or the platform itself) 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 also known as Platform Builders, 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.

See it in action

OAM Kubernetes Runtime is the officially maintained OAM plugin for Kubernetes.

OAM Kubernetes Runtime is a joint effort with the Crossplane community. Furthermore, to get started with an example of using OAM to deliver both applications and cloud resources in unified approach, please follow the end-to-end getting started doc in Crossplane.

The Specification

The specification convention adopts Kubernetes Resource Model which we believe will become the standard interface for the majority of platforms in the future.

• Notational Conventions
• Purpose and Goals
• Overview and Terminology
• API Resource Specification
  • Application Developers
    • Components
  • Application Operators
    • Application Scopes
    • Traits
    • Application Configuration
  • Infrastructure Operators/Platform Builders
    • Workload Definition
• Practical Considerations
• Design Principles

Community

Versioning

Since July 2020, changes to the specification are versioned according to Semantic Versioning 2.0 and described in its release page. Layout (e.g. repo structure, doc format etc) changes are not versioned. Specific implementations of the specification (e.g. OAM Kubernetes Runtime ) should specify which version they implement.

Changes to the change process (e.g. governance model, review/approve process etc) itself are not currently versioned but may be independently versioned in the future.

Milestones

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

Triaging

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.

Contributing

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.

Resources

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