 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.
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.
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
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 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
- Application Operators
- Infrastructure Operators/Platform Builders
- Practical Considerations
- Design Principles
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 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.
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.
| 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/ |
| @oam_dev |
Come find community blogs and conference talks about OAM in community/talks_and_blogs.md.