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!"
I think the tricky part of the sale will be in abstracting away Kubernetes; or at least, not adopting its conventions for registration and discovery of resources/endpoints. You can keep those and not use Kubernetes, which is more or less how Knative went about it (insofar as it's possible to create an implementation that's Knative without using Kubernetes).
I am however overall very sympathetic to the idea that Kubernetes never drew a crisp line between roles.
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.
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.
Interesting - if you don't mind indulging me a little, it was surprising to me that you chose kubernetes as the first implementation for this standard. After all, if a large part of OAM's functionality is provided by k8s out of the box (auto-scaling, for example) it's not very useful to someone who knows the existing tech. Kubernetes is, by and large, already portable with minimal dev resources between the major cloud vendors and/or on-prem resources.
On the other hand, if you can pair already-written software with a collection of VMs and place an OAM layer between the machines and business logic, the portability of your code between OAM-compatible vendors becomes a selling point for the standard. I know a large project like this is a team effort, but can you shed any light on the reasons behind your decision-making and prioritization towards kubernetes?
OAM is the app mgmt API for K8s, while not only for K8s. So implement it firstly on K8s is a natural choice. You may argue hey why I need app mgmt API for K8s. Well, have you ever tried to expose full Deployment api for developers to describe their app? My personal experience is super messy ...
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.
My original thinking was that Kubernetes has similar goals of providing platform-agnostic configuration for deploying applications, services, ingresses, and configuration. I now understand OAM as something a step above that can run on Kubernetes (via Rudr) but also on other platforms, perhaps like Swarm and Mesos?
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.
