Why OMS?

Microservices, by design, are intended to be highly reusable, operational-specific and language-agnostic. This guide defines the standard that defines how to interface with microservices to provide a blueprint for consistency and reusability. By following this documentation, developers will be able to create a platform that is well-documented and portable while not compromising flexibility.

The old way of communicating software architecture and design through whiteboards and diagrams is immediately out of date and often becomes difficult to read and understand. By mapping your microservice architecture using pre-defined yaml by OMS, developers are given a way to describe architecture and operational requirements as human-readable structured data.

Having these models in plain text files gives developers a framework to effectively communicate architecture, service to service communication, and operational complexities to many different audiences.

Illustration showing how OMS interacts with data

The Twelve-Factor Microservice

Inspired by The Twelve-Factor App

Domain Specific

Specialized to the domain and encapsulating the full API of the domain.


For portability and re-usability (ex. Docker, rkt or FaaS).


Written in any programming language.


Not be tied to one platform. Platforms designed to interface with OMS compliant services can interact with all services.

Any Interface

Free to choose any communication interface.


Automatically generated and actionable through the `oms.yml`.


List all actions the service can perform, including the arguments and the output.


Services must be stateless.

Cloud Events

Use a common specification for describing event data.


Include health, metrics, resources, and logs.


Not depend on any other service (aka container coupling).


All service configuration must be documented.

Join the discussion

We are under development and open to contribution.
100% open source.