[vturecek]

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.

[jeethsuresh]

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?

[resouer]

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 ...