vturecek

Yes precisely! OAM is meant to provide some consistency and standardization to this practice, while fully expecting each platform to have unique capabilities and requirements that can be surfaced through the model. It's really illuminating how often we hear "oh hey we're trying to do something very similar to OAM!"

Interestingly, what we found through our research was that nobody could agree on a definition of "application" in a microservices world. The way OAM is designed currently doesn't enforce a rigid "application" structure for services. We have a concept of application scopes that can be used to place application-like boundaries around groups of services (modeled as "components" in OAM). For example, grouping services in a "health" scope where the health of each service in the group is evaluated when any one of the services is upgraded as a trigger for automated rollback is something application scopes are designed for.

disclosure: am one of the OAM authors.

The overarching idea with OAM is to standardize the model by which applications are composed and operated, regardless of the environment you end up working in. So as you go from one platform to another, you have a consistent experience and a transferable process. We fully expect the implementing platform capabilities to differ, and the model is designed around this assumption. I think some standardization here is valuable.

At the same time, we aim to improve application modeling on systems like Kubernetes that currently focus more on container infrastructure.

disclosure: I'm one of the spec authors.

Yeah your understanding is spot on, glad that was helpful!

I can imagine platforms choosing to adopt the Kubernetes API for container infrastructure, but it is still the Kubernetes API and it seems like keeping up with changes would be difficult. And there isn't really much in the way of first-class application modeling there, so that's how we ended up with a separate spec specifically for that, with the explicit goal of not being tied to any one implementation.

Something like Swarm or Mesos could implement it, but we're also considering things like cloud PaaS, internal on-prem platforms, and even down to small device runtimes.

Yup, that's how the Open Application Model is implemented for Kubernetes. The OAM spec format closely resembles the spec format for Kubernetes resources so if you use Kubernetes it should already feel familiar. But it can be implemented by any platform.

The idea is to define a standard model for describing distributed applications, so as you go from one platform to another, you get a consistent way of doing things. The actual features that are exposed through the model can be different on each platform that implements it (e.g., platform A has a basic autoscaler, platform B has an advanced autoscaler, etc), but the way you describe and operate the application is consistent.

disclaimer: I'm one of the spec authors