Inspired by The Twelve-Factor App.
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 OMG Compliant services can interact with all services.
Free to choose any communication interface.
Automatically generated and actionable through the microservice.yml.
List all actions the service can perform, including the arguments and the output.
Services must be stateless.
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.
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 OMG, 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.
Focus is stressed on services being highly reusable between applications and platforms.
Define how to interface with the service, lifecycle management, scaling, among other requirements.
Services inherit documentation through a well defined configuration of commands, arguments and output.