11 ms·

Open Application Model – An open standard for defining cloud native apps

67 points by geordee 6y ago

falcolas 6y ago
An abstraction (OAM) 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).
- jjacobson93 6y ago
  Computer science is all about abstractions. You can keep on going down with your examples: VMs are an abstraction on top of an operating system, which is an abstraction on top of virtual memory, on top of a physical machine... 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.
- nine_k 6y ago
  Abstraction is what powers IT, what allows it to scale as immensely as it did. It hides the irrelevant details, handles it for you. 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.)
- linkdd 6y ago
  Imagine a developer: > 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
  - tmpz22 6y ago
    > 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.
    - linkdd 6y ago
      > its called a PaaS 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?
      - tmpz22 6y ago
        K8s is one of many options to collaborate and scale applications and for many organizations it is not the best option. It also comes with lots of vendor lock-in if you're using a service like GKE, EKS, or AKE, or integrate with any of their loadbalancer or storage solutions! 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 https://github.com/dokku/dokku.
        linkdd 6y ago
        Yes K8s is one of many options, but one that can translate to many situations. I'd still choose it over anything else when I need more than a `docker run` on a server. Thanks for the link btw.
        tmpz22 6y ago
        No worries and maybe I am being harsh here but this whole thing seems like a couple big providers trying to push their own idioms on the DevOps industry, an industry which is already saturated on dishonest marketing kool-aid. "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.
- jimmyed 6y ago
  Reminds me of SICP.
  - fengjingchao 6y ago
    If we all use LISP the whole tech stack would be much simpler :)
    - resouer 6y ago
      Agree. I must thank OSI layers model, so I don't need to program against TCP packets ...
- resouer 6y ago
  Complaining OAM should not be implemented on K8s doesn't make sense to me. 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.
outside1234 6y ago
Don't get it. Seems like someone is trying to make Kubernetes work on Service Fabric or something.
- nerdyyatrice 6y ago
  I wonder if you can explain why does it smell like SF?
- rektide 6y ago
  they're trying to make any service fabric work
- fengjingchao 6y ago
  Not make k8s work on service fabric. It is to provide a common platform so that the community users could build their own service fabric in an easier way.
- resouer 6y ago
  Actually it will be interesting to see k8s work on service fabric, though it seems SF itself is not interested in this (it's not even quite alive).
- anonymousDan 6y ago
  What is service fabric?
  - linkdd 6y ago
    A google search gives me https://github.com/microsoft/service-fabric https://github.com/microsoft/service-fabric Not sure if that's what "parent" meant.
juliangamble 6y ago
The spec doesn't appear to address the 12-factor app spec which does a similar job in a more general way. https://github.com/oam-dev/spec/search?q=12+factor https://github.com/oam-dev/spec/search?q=12+factor https://12factor.net/ https://12factor.net/
- linkdd 6y ago
  Doesn't the 12-factor spec just recommend some practices about writing your app, where OAM is about the infrastructure spec?
  - fengjingchao 6y ago
    YESSSS! That's exactly what I want to say as well :D
- nerdyyatrice 6y ago
  I wonder why do you think OAM should follow the 12-factor app spec? I personally have never heard of a spec created to address another spec.
tyingq 6y ago
Edit: Yep, wrong thread, thanks.
- linkdd 6y ago
  wrong thread?
gijoeyguerra 6y ago
https://12factor.net/ https://12factor.net/
wonderflow 6y ago
There's a K8s implementation of OAM called KubeVela (https://github.com/oam-dev/kubevela https://github.com/oam-dev/kubevela )
fengjingchao 6y ago
Hi, OAM and KubeVela author here. 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.
notmars 6y ago
Oh the longing and despair of missing Docker Swarm... It was missing so little...it was so well done and simple, elegant. Docker Swarm is now the betacam of container orchestration solution. hopefuly all these layers (kube-> custom kube -> OA*) will soon converge and fold themselves into something grandiose, efficient and simple. How eager I am to be there :-)
- nerdyyatrice 6y ago
  I think that's the direction KubeVela is going
- antman 6y ago
  Have you tried Nomad?
  - linkdd 6y ago
    Taken directly from the Nomad website[1]: > 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). [1] - https://www.nomadproject.io/docs/nomad-vs-kubernetes https://www.nomadproject.io/docs/nomad-vs-kubernetes
- cdrx 6y ago
  Swarm isn't dead, it works just fine and is being actively maintained.
- rektide 6y ago
  Kube's main problem is that it's not quite grandiose enough, doesn't have a general encapsulation system. 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.
afterwalk 6y ago
I really like this approach for simplifying Kubernetes. A few projects similar to OAM in that it provides a higher level "Application" CRD: https://github.com/vmware-tanzu/carvel-kapp https://github.com/vmware-tanzu/carvel-kapp https://github.com/k11n/konstellation https://github.com/k11n/konstellation https://github.com/kalmhq/kalm https://github.com/kalmhq/kalm (We ended using this one, which came with a set of matching web UI)
- nerdyyatrice 6y ago
  Have you looked at https://www.shipa.io/ https://www.shipa.io/
withinboredom 6y ago
It should be named Open Kubernetes Application Model. If I'm understanding correctly, it should be "portable" to other orchestrators or even bare metal. However, it seems to be quite leaky of the underlying Kubernetes stuff.
- rektide 6y ago
  Yeah, well, survival instinct. They could never compete in a void. They need to borrow/interop with what everyone already enjoys.
- resouer 6y ago
  Reusing Kubernetes Resource Model to build app-centric platform have many benefits: 1. Work seamlessly with any CI CD solutions which work with Kubernetes. 2. Clarity in api versions in the spec entity. 3. Adopt widely used best practices such as metadata, spec & status. 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.

67 points by geordee 6y ago

An abstraction (OAM) 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).

jjacobson93 6y ago
Computer science is all about abstractions. You can keep on going down with your examples: VMs are an abstraction on top of an operating system, which is an abstraction on top of virtual memory, on top of a physical machine... 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.
nine_k 6y ago
Abstraction is what powers IT, what allows it to scale as immensely as it did. It hides the irrelevant details, handles it for you. 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.)
linkdd 6y ago
Imagine a developer: > 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
- tmpz22 6y ago
  > 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.
  - linkdd 6y ago
    > its called a PaaS 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?
    - tmpz22 6y ago
      K8s is one of many options to collaborate and scale applications and for many organizations it is not the best option. It also comes with lots of vendor lock-in if you're using a service like GKE, EKS, or AKE, or integrate with any of their loadbalancer or storage solutions! 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 https://github.com/dokku/dokku.
      - linkdd 6y ago
        Yes K8s is one of many options, but one that can translate to many situations. I'd still choose it over anything else when I need more than a `docker run` on a server. Thanks for the link btw.
        tmpz22 6y ago
        No worries and maybe I am being harsh here but this whole thing seems like a couple big providers trying to push their own idioms on the DevOps industry, an industry which is already saturated on dishonest marketing kool-aid. "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.
jimmyed 6y ago
Reminds me of SICP.
- fengjingchao 6y ago
  If we all use LISP the whole tech stack would be much simpler :)
  - resouer 6y ago
    Agree. I must thank OSI layers model, so I don't need to program against TCP packets ...
resouer 6y ago
Complaining OAM should not be implemented on K8s doesn't make sense to me. 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.

outside1234 6y ago

Don't get it. Seems like someone is trying to make Kubernetes work on Service Fabric or something.

nerdyyatrice 6y ago
I wonder if you can explain why does it smell like SF?
rektide 6y ago
they're trying to make any service fabric work
fengjingchao 6y ago
Not make k8s work on service fabric. It is to provide a common platform so that the community users could build their own service fabric in an easier way.
resouer 6y ago
Actually it will be interesting to see k8s work on service fabric, though it seems SF itself is not interested in this (it's not even quite alive).
anonymousDan 6y ago
What is service fabric?
- linkdd 6y ago
  A google search gives me https://github.com/microsoft/service-fabric https://github.com/microsoft/service-fabric Not sure if that's what "parent" meant.

juliangamble 6y ago

The spec doesn't appear to address the 12-factor app spec which does a similar job in a more general way. https://github.com/oam-dev/spec/search?q=12+factor https://github.com/oam-dev/spec/search?q=12+factor https://12factor.net/ https://12factor.net/

linkdd 6y ago
Doesn't the 12-factor spec just recommend some practices about writing your app, where OAM is about the infrastructure spec?
- fengjingchao 6y ago
  YESSSS! That's exactly what I want to say as well :D
nerdyyatrice 6y ago
I wonder why do you think OAM should follow the 12-factor app spec? I personally have never heard of a spec created to address another spec.

tyingq 6y ago

Edit: Yep, wrong thread, thanks.

linkdd 6y ago
wrong thread?

gijoeyguerra 6y ago

https://12factor.net/ https://12factor.net/

wonderflow 6y ago

There's a K8s implementation of OAM called KubeVela (https://github.com/oam-dev/kubevela https://github.com/oam-dev/kubevela )

fengjingchao 6y ago

Hi, OAM and KubeVela author here. 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.

notmars 6y ago

Oh the longing and despair of missing Docker Swarm... It was missing so little...it was so well done and simple, elegant. Docker Swarm is now the betacam of container orchestration solution. hopefuly all these layers (kube-> custom kube -> OA*) will soon converge and fold themselves into something grandiose, efficient and simple. How eager I am to be there :-)

nerdyyatrice 6y ago
I think that's the direction KubeVela is going
antman 6y ago
Have you tried Nomad?
- linkdd 6y ago
  Taken directly from the Nomad website[1]: > 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). [1] - https://www.nomadproject.io/docs/nomad-vs-kubernetes https://www.nomadproject.io/docs/nomad-vs-kubernetes
cdrx 6y ago
Swarm isn't dead, it works just fine and is being actively maintained.
rektide 6y ago
Kube's main problem is that it's not quite grandiose enough, doesn't have a general encapsulation system. 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.

afterwalk 6y ago

I really like this approach for simplifying Kubernetes. A few projects similar to OAM in that it provides a higher level "Application" CRD: https://github.com/vmware-tanzu/carvel-kapp https://github.com/vmware-tanzu/carvel-kapp https://github.com/k11n/konstellation https://github.com/k11n/konstellation https://github.com/kalmhq/kalm https://github.com/kalmhq/kalm (We ended using this one, which came with a set of matching web UI)

nerdyyatrice 6y ago
Have you looked at https://www.shipa.io/ https://www.shipa.io/

withinboredom 6y ago

It should be named Open Kubernetes Application Model. If I'm understanding correctly, it should be "portable" to other orchestrators or even bare metal. However, it seems to be quite leaky of the underlying Kubernetes stuff.

rektide 6y ago
Yeah, well, survival instinct. They could never compete in a void. They need to borrow/interop with what everyone already enjoys.
resouer 6y ago
Reusing Kubernetes Resource Model to build app-centric platform have many benefits: 1. Work seamlessly with any CI CD solutions which work with Kubernetes. 2. Clarity in api versions in the spec entity. 3. Adopt widely used best practices such as metadata, spec & status. 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.