Open Application Model – An open standard for defining cloud native apps
oam.dev
oam.dev
So everyone which uses Helm. Which is ok, it works decently, but it's also, like, kind of a lot. The target that we've converged on is just a little too sophisticated to make shipping stuff accessible.
We need more grandiosity, in order to be adequately simple.
> Kubernetes and Nomad support similar core use cases for application deployment and management, but they differ in a few key ways.
> Kubernetes aims to provide all the features needed to run Docker-based applications including cluster management, scheduling, service discovery, monitoring, secrets management and more.
> Nomad only aims to focus on cluster management and scheduling and is designed with the Unix philosophy of having a small scope while composing with tools like Consul for service discovery/service mesh and Vault for secret management.
Compare Kubernetes Pods and Deployments to Nomad, and the full Kubernetes ecosystem to the full Hashicorp ecosystem please.
IMHO, Vault and Consul are very hard to operate correctly, at least as hard as a Kubernetes cluster on-premise (managed Kubernetes does not count).
We originally created these specification and projects to facilitate delivering applications to Kubernetes without exposing all the nitty-gritty details. There's a lot to do to achieve such goal besides managing application templates, clusters, environments, cloud resources and service bindings, etc. We have seen common patterns rising up within companies of medium and large sizes. That's why we created them to provide common platform for others to build their own application platforms.
Let me know if you have any questions and I will be available here to answer them.
https://github.com/vmware-tanzu/carvel-kapp
https://github.com/k11n/konstellation
https://github.com/kalmhq/kalm (We ended using this one, which came with a set of matching web UI)
Not sure if that's what "parent" meant.
Overall, we should be aware that the complexity of Kubernetes does NOT lie in its api model (Group, Version, Kind etc). Also, an abstraction adopts this model does not leak anything in underlying Kubernetes runtime.
On the top of an abstraction (K8s Custom Object specification)
On the top of an abstraction (Kubernetes, et.al.)
On top of another abstraction (Containers)
On top of another abstraction (VMs)
I wonder if the Dyke-sealing-boy is available for the inevitable leaks?
On a slightly more serious note, even though I participated in OAM early in the process, I've never really seen the value in the abstraction it provides, especially since it's using the Kubernetes Custom Object Model to run on Kubernetes (first, not only, I know).
Just like Python is an abstraction on top of C, which is an abstraction on top of assembly language, which is an abstraction of a CPU and memory, etc.
There’s reasons for all of the abstractions.
> On top of another abstraction (VMs)
Who does not need to badly handle infrastructure
> On top of another abstraction (Containers)
Who does not need to badly handle isolation
> On the top of an abstraction (Kubernetes, et.al.)
Who does not need to badly handle scalability
> On the top of an abstraction (K8s Custom Object specification)
Who does not need to badly handle deployment
> An abstraction (OAM)
Who just wants to ship their code
That exists, its called a PaaS. Kubernetes was not meant to be a PaaS.
I'm starting to think people create these orgs to forward their own career, products, or companies.
You mean like Heroku?
Kubernetes allows your ops and developers to collaborate and scale and avoid vendor lock-in.
How does a PaaS (like Heroku?) allows that?
Oracle and Alibaba building a large abstraction on top of kubernetes, to do something kubernetes was not designed to do (though capable of doing), is not the direction I personally believe distributed systems development should standardize around.
There are tons of self-hosted PaaS options that are not built on top of massive abstractions and provide better functionality to their users. Since you mentioned Heroku i'll mention https://github.com/dokku/dokku.
That's why if you had a chance to look at Dokku and any other "better" self-hosted PaaS offerings, they are dead. Ppl today choose to use Kubernetes to build abstractions atop and OAM is a battle tested option to achieve this with better clarity and interpretability. Many companies are shifting away from Cloud Foundry and OpenShift to this approach.
Thanks for the link btw.
"Our solution is way better then all those pre-existing solutions!".
No. No it isn't. Stop acting like you're helping me when you're really selling me something.
And yes I agree those cloud providers will make more money with this trend.
Kubernetes is NOT a PaaS, it's by design for you to create abstractions atop and serve your own purposes. And OAM is a great option if you want to build things like app PaaS or app delivery systems with k8s.
It seems you either have mis-understanding on OAM or Kubernetes, based on you are involved in OAM, it's likely the later case.
Abstraction is not always expensive, except at wrapping your head around it. (Though in the case of Kubernetes, the runtime and operations cost may be noticeable.)