anubhavpulkit / spec

The Open Application Model specification

Open Application Model Specification

What is NEW!
May 18th, 2020. Crossplane becomes the standard Kubernetes implementation of OAM spec!
Mar 27th, 2020. OAM v0.2.0 is RELEASED! The new spec is highly extensible and native to Kubernetes runtime. Check the spec and What's new in OAM v0.2.0 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.

Relations between various OAM resources

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

Versioning

Releases of the specification are versioned according to Semantic Versioning 2.0 and described in OAM release page. Implementations of the specification are required to specify which version they implement.

Changes to the API objects

Changes to the API objects in this specification follows on compatibility and incompatible api changes defined in Kubernetes API convention. It doesn't couple with release version of the specification.

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.

Community

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.

Item	Value
Mailing List	https://groups.google.com/forum/#!forum/oam-dev
Community meeting info	Bi-weekly (Starting Oct 22, 2019), Tuesdays 10:30AM PST
Meeting link	https://zoom.us/j/271516061
APAC Friendly Community meeting	Bi-weekly APAC (Starting May 19, 2020), Tuesdays 19:00PM GMT+8
Meeting link APAC Friendly meeting	https://zoom.com.cn/j/2847572020
Meeting notes	Notes and agenda
Meeting recordings	Recordings
IM Channel	https://gitter.im/oam-dev/
Twitter	@oam_dev

Resources

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