Live data from Hacker News

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

oam.dev

41–47 of 47 posts

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

#41
post #28

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 :-)

Swarm isn't dead, it works just fine and is being actively maintained.

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

#42
post #40
post #28

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 :-)

Have you tried Nomad?

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

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

#43
post #32
post #16

Earlier quoted context omitted.

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.

There's no such industry named "build app-centric platforms".

The shoveling of "Cloud Native" is in part a bid to sell cloud services at AWS, Azure, GCP, Oracle, Alibaba, etc. Just because the engineers on the ground doing the work conveniently ignore this point doesn't mean that the executives who ultimately green light and fund these projects aren't considering it the #1 priority.

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

#44
post #28

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 :-)

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.

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

#45

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.

Yeah, well, survival instinct. They could never compete in a void. They need to borrow/interop with what everyone already enjoys.

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

#46
post #43
post #32

Earlier quoted context omitted.

There's no such industry named "build app-centric platforms".

The shoveling of "Cloud Native" is in part a bid to sell cloud services at AWS, Azure, GCP, Oracle, Alibaba, etc. Just because the engineers on the ground doing the work conveniently ignore this point doesn't mean that the executives who ultimately green light and fund these projects aren't considering it the #1 priority.

More and more applications will be built on cloud with or without "cloud-native", we can't stop this trend or arguing technologies that intend to make this process smoother/easier.

And yes I agree those cloud providers will make more money with this trend.

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

#47

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.

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.

Post reply on HN