Demo the CNCF's SIG

[stevepeak]

Below is the copy to be posted at in the SIG group to propose a demo of the OMS when we are ready.

Feel free to edit as needed.

---

---

Intro & demo the Open Microservice Specification at SIG meeting

The Open Microservice Specification turns containers into cloud libraries in a declarative way that defines and exposes the events, actions and APIs inside containerized software.

Background

This spec we hope to donate to the SIG/LF/CNCF (or whoever it’s best fit). I’ll be honest, we didn’t want to build this spec, I’m sure like most specs it came out of a need for transparency and collaboration. The OMS is no exception to this. Containers clearly provide a powerful way to deliver and run software anywhere, but when you discover a container, say on Docker Hub, you are left with only a readme to understand what the service does... We can do better. Companies like Zapier, Clay.run, Tray, Zenaton, Storyscript, SAP, dozens more and thousands of business that build microservice architectures consume containers for breakfast. However, we still have no way to consume containers as libraries.

The specifications is being developed by Storyscript, a company that is building glue-code for microservices. We discovered that this problem (that OMS solves) is bigger than just Storyscript and the opportunity to turn black-box containers into light-box libraries is valuable and an obvious next step for containers.

Problem Build specifications (like Dockerfile) answer the question of how to build a container but do not illuminate the lifecycle, events, actions, protocols, serialization and data moving to/fro the container. Spoiler, that’s what OMS does. The OpenAPI, AsyncAPI, and GraphQL specifications make an assumption that limit their capabilities: they assume the server is running and managed. Containers don't have that privilege. A runtime is responsible for the containers lifecycle, logs, metrics, health checks, and environment variables. Furthermore, the protocol and serialization should be left up to the developer, unlike OpenAPI which requires HTTP, the OMS may support any number of protocols matches with any serialization (json, xml, etc) providing an opinion-free spec (developers love this) that can be adopted easily.

Solution Applying the Open Microservice Spec's oms.yml provides a declarative way to define and expose the events, actions and APIs inside containerized software.

Benefits

1. Automatically generate documentation.
2. Commoditize access to containers.
3. Complete with the OMS App (like Postman but for microservices) that encourages healthy service building and completeness.

Mission

1. Document containers listed in the Docker Hub (or equivalent products)
2. Commoditize services so that any company (Zapier, Clay.run, Tray, IFTTT, and any business) can consume microservices like libraries.
3. Collaboration. The best tech stack is one that is easiest to contribute to, more inclusive and diverse: the OMS provides a sandbox for developers to build services in a more cohesive way.
4. Non-opinionated contract that empowers engineers to focus on their service and what tech they are familiar with (ie. no forcing Go + gRPC, let the engineer choose language+protocol).

We would love to demonstrate the OMS at sig-app-delivery meeting.

Proposed Agenda: Introduction - 5 minutes Demo - 7 minutes QA - 10 minutes

Important links: GitHub: https://github.com/microservices Slack: #oms in CNCF Slack room Website: https://openmicroservices.org