Open Application Model – An open standard for defining cloud native apps
1–10 of 47 posts
Re: Open Application Model – An open standard for defining cloud native apps
#2An 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).
Re: Open Application Model – An open standard for defining cloud native apps
#3Don't get it. Seems like someone is trying to make Kubernetes work on Service Fabric or something.
Re: Open Application Model – An open standard for defining cloud native apps
#4Don't get it. Seems like someone is trying to make Kubernetes work on Service Fabric or something.
they're trying to make any service fabric work
Re: Open Application Model – An open standard for defining cloud native apps
#5The spec doesn't appear to address the 12-factor app spec which does a similar job in a more general way.
Re: Open Application Model – An open standard for defining cloud native apps
#6An 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 abstra…
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.)
Re: Open Application Model – An open standard for defining cloud native apps
#7An 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 abstra…
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
Re: Open Application Model – An open standard for defining cloud native apps
#8Edit: Yep, wrong thread, thanks.
Re: Open Application Model – An open standard for defining cloud native apps
#9The 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://12factor.net/
Doesn't the 12-factor spec just recommend some practices about writing your app, where OAM is about the infrastructure spec?
Re: Open Application Model – An open standard for defining cloud native apps
#10Edit: Yep, wrong thread, thanks.
wrong thread?