Microsoft launches new open-source projects around Kubernetes and microservices

Maybe a better link: <a href="https:&#x2F;&#x2F;cloudblogs.microsoft.com&#x2F;opensource&#x2F;2019&#x2F;10&#x2F;16&#x2F;announcing-open-application-model&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloudblogs.microsoft.com&#x2F;opensource&#x2F;2019&#x2F;10&#x2F;16&#x2F;annou...</a><p>and to the GitHub projects themselves <a href="https:&#x2F;&#x2F;openappmodel.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;openappmodel.io&#x2F;</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;oam-dev&#x2F;spec&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;oam-dev&#x2F;spec&#x2F;</a> <a href="https:&#x2F;&#x2F;github.com&#x2F;oam-dev&#x2F;rudr&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;oam-dev&#x2F;rudr&#x2F;</a>

Somehow these enterprise people have turned Kubernetes, which basically was an advanced job scheduler for compute resources, into a unnecessary complex monster (just look at the LOC of kube-api). And that&#x27;s still pretty decent compared to all the other projects in the ecosystem (looking at OpenShift, Istio ...). I really don&#x27;t believe a lot of people have a valid use case for these projects like OAM when you look at the complexity, failure cases and administrative tasks these systems introduce.<p>The one of the main design ideas behind the original Borg system (which Kubernetes is inspired by) was utilisation of resources and simplicity. Now we just stuff all the compute power we got with unnecessary proxy systems that provide minimal value. I truly believe we have lost our way.

<p><pre><code> OAM is essentially a YAML file. It can be put in a service catalog or marketplace and deployed from there. But what’s maybe most important, says Russinovich, is that the developer can hand off the specification to the ops team and the ops team can then deploy it without having to talk to the developer. </code></pre> This statement sounds very backwards to me. Isn&#x27;t this increasing the separation between devs and ops which we want to get rid of?

Dapr looks like Microsoft&#x27;s answer to Istio - anecdotally, I&#x27;ve never gotten Istio to work (as recently as a few months ago) so I&#x27;ll have to give this one a try at some point to see if they&#x27;ve done a better job.<p>OAM though, perplexes me. Even the justification - that k8s is out of scope of the developer, and is handled by ops - speaks to a misunderstanding of some of the advantages clusters provide. Some research [1] tells me that developers author &quot;components&quot; which encapsulate singular parts of an architecture, and are connected by operators into an application. And then auto-scaling is handled by &quot;traits&quot;, which are entirely separate? It&#x27;s interesting, but it seems to largely replicate (and act as a translation layer for) existing k8s features. Maybe that&#x27;s the real value prop here, and the techcrunch article buried the lede - by defining components and traits through OAM you can move to any cloud-based model that supports the manifest spec (thus avoiding the high learning curve of something like k8s). Even so, I have a sinking feeling that most of this will be folded into the ever-changing definition of devops, so small teams that manage an app&#x27;s entire lifecycle (and are told to get on board with the new-fangled dealio by management) will have another layer of indirection to debug when something inevitably goes wrong. If Azure comes out with an implementation of OAM that uses their VSIs, I&#x27;ll get interested. Then it&#x27;ll at least provide real value&#x2F;choice, and hopefully make it easier to migrate existing workloads that don&#x27;t need an entire machine for themselves onto a k8s cluster.<p>[1] <a href="https:&#x2F;&#x2F;cloudblogs.microsoft.com&#x2F;opensource&#x2F;2019&#x2F;10&#x2F;16&#x2F;announcing-open-application-model&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloudblogs.microsoft.com&#x2F;opensource&#x2F;2019&#x2F;10&#x2F;16&#x2F;annou...</a>

I don&#x27;t see a link to dig into the Open Application Model, and I don&#x27;t have time to search for one tonight. Maybe kubernetes can benefit from a higher level of abstraction than helm charts provides, but I would need to see some use cases. I did get a kick out of:<p>&gt;&gt; He also argues that Kubernetes itself is too complicated for enterprise developers. “At this point, it’s really infrastructure-focused,” he said. “You want a developer to focus on the app. What we saw when we talked to Kubernetes shops, they don’t let developers near Kubernetes.”<p>Not sure what he means by &quot;get near&quot; but it&#x27;s really not that complicated to use kubectl to interrogate and modify the cluster. All of the back end engineers on our small team are comfortable with it.

All of this is well and good. Now find folks who understand the entire stack and can support it.<p>Tell me you are saving money after you hire them :)

Basically this is a helm chart. Which is one of the problems of k8s - a typical application consists of multiple services that need to be deployed together.<p>In Docker Swarm, that&#x27;s a Stack. K8s has no equivalent. So there&#x27;s no answer to &quot;how do i deploy&#x2F;update my flask api and celery workers together&quot;

I’ve really thought that something like this was needed for a long time. Why isn’t there standardised containers for user management and permissions, authentication, scheduling things, processing events, caching say... there are off the shelf containers for simple things like proxying but nothing that understands your application. And it looks like they have taken it further to include Functions and Actors which might be useful and allow easier scaling of certain things. Let’s hope this goes some way to addressing that.

Links to related discussions:<p>* Dapr: an open-source project to make it easier to build microservices: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21272098" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21272098</a><p>* Announcing the Open Application Model (OAM):<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21272082" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21272082</a>

This is exciting!<p>When Docker came out, I was just finishing an in-house-Heroku style project at my employer, based on LXC containers. I watched as Deis came along, promising to give the same benefits in an open platform. I was sad to see Deis go away after the Microsoft acquisition. The industry got all excited about Kubernetes, but it seemed to me like we were backsliding from progress that had been made toward a 12 Factor platform. (<a href="https:&#x2F;&#x2F;www.12factor.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.12factor.net&#x2F;</a>) . It&#x27;s very encouraging to see that coming back.

We&#x27;ve been working on something similar for a few years now. Micro is a runtime for microservices <a href="https:&#x2F;&#x2F;github.com&#x2F;micro&#x2F;micro" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;micro&#x2F;micro</a>. We primarily focused on Go and are moving towards multilanguage via a http api, proxy and SDKs much like dapr.

Worry about vendor lock-in is real.<p>RedHat OpenShift (yes yes IBM) is gaining momentum because of it. But the field is still wide open. And the burden will fall on small ISVs to provide open solutions around data portability, redundancy, security, and a host of other concerns.<p>In the early days of Cloud technologies, the original vision was highly commoditized. You&#x27;d pull a Docker container from a registry hub and perhaps not even know where it ran. Perhaps even an exchange would handle pricing and performance. Instead, we have the Big 4 vendors in a highly fragmented space offering roughly the same services.

I haven&#x27;t used k8s that much, so I can&#x27;t see what features OAM (or the implementation, rudr) adds to k8s. Could someone provide me with some insights?

I think Microsoft is becoming an open-source company!

Trying to manage an “application” in microservices world is misunderstanding the whole concept of microservices, IMO.

First I thought dapper, but that was google, and it was about distributed tracing... but sounds very close (and have some relation - e.g. you need sidecar to capture network traffic, and propagate tokens for distributed tracing - that is unless you want to change your source code to do so)...

Gabe here from the Azure team. Happy to answer questions about Dapr and OAM.

How does Dapr (or the Actors in Dapr) relate to Microsoft Orleans?

Dapr looks like a slightly beefier sidecar-based service mesh.

Referring to Microsoft&#x27;s original announcement post of OAM, (<a href="https:&#x2F;&#x2F;cloudblogs.microsoft.com&#x2F;opensource&#x2F;2019&#x2F;10&#x2F;16&#x2F;announcing-open-application-model&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloudblogs.microsoft.com&#x2F;opensource&#x2F;2019&#x2F;10&#x2F;16&#x2F;annou...</a>), the problem of defining application workflows and their dependencies that OAM is addressing is genuine. We have also faced this problem as part of providing Kubernetes-native platform stacks to our customers.<p>It will be interesting to see how OAM evolves, especially since it is coming from the same team that is leading the charge on Helm and CNAB (<a href="https:&#x2F;&#x2F;cloudblogs.microsoft.com&#x2F;opensource&#x2F;2018&#x2F;12&#x2F;04&#x2F;announcing-cnab-cloud-agnostic-format-packaging-running-distributed-applications&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloudblogs.microsoft.com&#x2F;opensource&#x2F;2018&#x2F;12&#x2F;04&#x2F;annou...</a>).<p>Here is what we have learnt about this space in the last one and a half years.<p>Application portability - While the point about application portability is true, if an organization has decided to adopt Kubernetes, the portability requirement is solved by Kubernetes itself to a large extent. If your application platform workflows are built as Kubernetes YAMLs, then they can be run on any cluster. Kubernetes YAMLs of built-in resources (Pod, Secret, etc.) and Custom Resources (MySQL, Postgres, etc.) can be leveraged to create such Kubernetes-native platform workflows. Our learning has been that a solution that focuses on solving the platform workflows problem on Kubernetes needs to augment existing Kubernetes tools such as Helm, Kustomize, etc. We have been developing such a tool (<a href="https:&#x2F;&#x2F;github.com&#x2F;cloud-ark&#x2F;kubeplus" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cloud-ark&#x2F;kubeplus</a>). Check out this blog post which provides detailed comparison between existing tools. <a href="https:&#x2F;&#x2F;medium.com&#x2F;@cloudark&#x2F;discovery-and-binding-of-kubernetes-custom-resources-in-multi-operator-environments-b5acf88fa639" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@cloudark&#x2F;discovery-and-binding-of-kubern...</a><p>On separation of concern between Devs &amp; Ops - Again with adoption of Kubernetes, our observation has been that Kubernetes YAML and the tooling around it such as Helm is becoming a common language of communication between Devs &amp; Ops. In our view the goal for anyone developing new tools&#x2F;frameworks in this space should be to help break the barriers that have existed between Dev and Ops teams further. One way we are trying to do this is by extending the vocabulary of ‘as-Code’ systems from the Infrastructure world to the ‘platform’ world of application development teams. Check out some of our work in this space primarily focusing on Kubernetes Custom Resources here - <a href="https:&#x2F;&#x2F;cloudark.io&#x2F;platform-as-code" rel="nofollow">https:&#x2F;&#x2F;cloudark.io&#x2F;platform-as-code</a>

Dapr sounds like it could be cool. Almost like a cloud function but with more intelligence.