14 ms·
Microsoft launches new open-source projects around Kubernetes and microservices
- andy_ppp 7y agoI’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.
- gabrtv 7y agoGabe from the Azure team here. You nailed it. We think that microservices building blocks enabled by extensible side-cars has a lot of potential. We’d love you to take it for a spin and provide some feedback on GitHub. :)
- mwjfussell 7y agoMarkF from the Azure team. We thought so too. Having seen developers reinvent the same capabilities time and time again, and seen the frustration when my favorite framework X did not have a certain capability, we wanted to provide a distributed system building block approach. And one that can be just dropped in with local calls without having to recompile in many different libraries. It is an approach that we have found to provide easier extensibility and also support.
- markbnj 7y agoI don't see a link to dig into the Open Application Model, and I don'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: >> 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.” Not sure what he means by "get near" but it'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.
- hajhatten 7y agoYes. If you don't trust your developers to use controls like kubectl, you have a bigger problem. And I'm sure it's easier to throw money at a project like this than to actually fix that problem.
- sheeshkebab 7y agoI think they meant get near editing Kubernetes yaml files (or some abstracted equivalent there of)
- rumanator 7y agoHere's a link to the Open Application Model spec. https://openappmodel.io/ https://openappmodel.io/
- markbnj 7y agoThanks!
- ubercow 7y agoMaybe a better link: https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-open-application-model/ https://cloudblogs.microsoft.com/opensource/2019/10/16/annou... and to the GitHub projects themselves https://openappmodel.io/ https://openappmodel.io/ https://github.com/oam-dev/spec/ https://github.com/oam-dev/spec/ https://github.com/oam-dev/rudr/ https://github.com/oam-dev/rudr/
- hardwaresofton 7y agoDapr looks like a slightly beefier sidecar-based service mesh.
- gabrtv 7y agoGabe from the Azure team here. The sidecar pattern is shared by a service mesh, so I understand the comparison. However Dapr is focused on enabling in-IDE experiences versus intercepting and proxying networking traffic like a service mesh.
- mwjfussell 7y agoMarkF from the Azure team. Dapr is not a service mesh, however it will work with service meshes such as itsio, linkerd etc. Dapr does provide direct service-to-service invocation which you can use in place of a service mesh if you want, however Dapr does not handle network policies or traffic management that service meshes do. Dapr is a side-car that is language agnostic, and using http or gRPC provides distributed system building blocks via open APIs for asynchronous pub-sub, stateful services, service discovery and invocation, actors and distributed tracing. All of this is extensible, so you can add new building block capabilities and only choose the use the ones you care about.
- jeethsuresh 7y agoDapr looks like Microsoft's answer to Istio - anecdotally, I've never gotten Istio to work (as recently as a few months ago) so I'll have to give this one a try at some point to see if they've done a better job. 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 "components" which encapsulate singular parts of an architecture, and are connected by operators into an application. And then auto-scaling is handled by "traits", which are entirely separate? It's interesting, but it seems to largely replicate (and act as a translation layer for) existing k8s features. Maybe that'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'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'll get interested. Then it'll at least provide real value/choice, and hopefully make it easier to migrate existing workloads that don't need an entire machine for themselves onto a k8s cluster. [1] https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-open-application-model/ https://cloudblogs.microsoft.com/opensource/2019/10/16/annou...
- gabrtv 7y ago> If Azure comes out with an implementation of OAM that uses their VSIs, I'll get interested. Gabe from the Azure team. VSIs? I'd love to understand this better.
- jeethsuresh 7y agoVirtual Server Instances - VMs :)
- vturecek 7y agoThe overarching idea with OAM is to standardize the model by which applications are composed and operated, regardless of the environment you end up working in. So as you go from one platform to another, you have a consistent experience and a transferable process. We fully expect the implementing platform capabilities to differ, and the model is designed around this assumption. I think some standardization here is valuable. At the same time, we aim to improve application modeling on systems like Kubernetes that currently focus more on container infrastructure. disclosure: I'm one of the spec authors.
- mweibel 7y agoOAM 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. This statement sounds very backwards to me. Isn't this increasing the separation between devs and ops which we want to get rid of?
- latchkey 7y agoI concur, my same reaction as well. Every place I've worked at where there was a line drawn in the sand like this, showed a huge amount of dysfunction, chair spinning and finger pointing.
- gabrtv 7y agoGabe from the Azure team here. If you’re talking about orgs where software is tossed over the wall from dev to ops, then I agree. The goal here is to empower the internal ops function to build self-service platforms with clean interfaces so developers can do what they do best, which is write code and business logic.
- latchkey 7y ago> "developers can do what they do best, which is write code and business logic" That is the exact mentality that I see as totally dysfunctional.
- resouer 7y agoUnfortunately, that's not what OAM could provide to you. OAM is just a contract between dev and ops so ops could tell what he has (Trait) in a way dev understand, and dev could tell ops what he want (Components) in a way easy to manage by ops. That's all.
- Lutger 7y agoAgree. This looks to me as if the audience is traditional enterprise who haven't yet adopted DevOps and to make kubernetes more accessible. But those are likely better served by either a PaaS or serverless solution. It doesn't inspire a great deal of confidence that the Azure CTO promotes this development model - if he isn't quoted out of context that is.
- malkia 7y agoFirst 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)...
- jmcomets 7y agoI haven't used k8s that much, so I can't see what features OAM (or the implementation, rudr) adds to k8s. Could someone provide me with some insights?
- rumanator 7y agoOn a previous HK discussion on OAM[¹], it was mentioned that the idea is to provide a higher level abstraction on kubernetes that enable developers to configure and deploy distributed applications in a platform-agnostic way. One of the author's of the OAM spec mentioned that an OAM abstraction might enable developers to deploy to k8s, docker swarm or Apache mesos with the same OAM config, provided that all platforms (or vendors) implement/support the OAM API. [1] https://news.ycombinator.com/item?id=21272082 https://news.ycombinator.com/item?id=21272082
- orthoxerox 7y agoAt first glance it looks similar to operators. Except operators are more suitable for system software, and this thing aims to simplify the deployment of business software.
- rumanator 7y agoLinks to related discussions: * Dapr: an open-source project to make it easier to build microservices: https://news.ycombinator.com/item?id=21272098 https://news.ycombinator.com/item?id=21272098 * Announcing the Open Application Model (OAM): https://news.ycombinator.com/item?id=21272082 https://news.ycombinator.com/item?id=21272082
- deleted 7y ago[deleted]
- Assortlist 7y agoLast season, Siakam came off the bench and became a key player in the team’s championship run. Many are hopeful that we see other players such as Anunoby who was plagued by injuries last year and Powell step up to the plate What remains to be seen is whether anyone currently on the roster can become the feature player that Leonard was. Fans will likely get a better sense when the preseason gets underway. The team is scheduled to play four games, two of which will be against the Houston Rockets in Japan. The team will receive their championship rings at the home-opener on Oct. 22 when they face the New Orleans Pelicans at Scotiabank Arena in Toronto. https://www.assortlist.com/ https://www.assortlist.com/
- Havoc 7y agoDapr sounds like it could be cool. Almost like a cloud function but with more intelligence.
- mwjfussell 7y agoMarkF from the Azure team here. The idea is to provide a function like experience with any programming language and then have common capabilities like saving state, sending events that your app can use with local host calls. And make this all extensible with components
- Havoc 7y ago>MarkF from the Azure team here. Glad to see you engage. Thanks to enterprise sub & monthly credit azure is def my favorite cloud right now :)
- naveen_ 7y agoI think Microsoft is becoming an open-source company!
- sandGorgon 7y agoBasically 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. In Docker Swarm, that's a Stack. K8s has no equivalent. So there's no answer to "how do i deploy/update my flask api and celery workers together"
- blairhudson 7y agoActually, Docker can now deploy stacks as a k8s “stack” resource: https://www.docker.com/blog/simplifying-kubernetes-with-docker-compose-and-friends/ https://www.docker.com/blog/simplifying-kubernetes-with-dock... This makes it especially easy for anyone transitioning from Docker Swarm to Kubernetes.
- sandGorgon 7y agoTrue. However the fact remains that k8s doesn't have a primitive here - so the toolsets (helm, docker stacks) have to manage it on a beat effort basis. In Swarm, the stack is an atomic unit. That's what Microsoft is trying to fix - the atomicity of an abstraction level that is higher than K8s Services. Not sure why they didnt do this as part of the k8s core committee process.
- cpuguy83 7y agoSwarm does not have a concept of a stack. This is purely client-side.
- fogetti 7y agoThanks for the link. I haven't heard about this before but it seems really useful.
- rumanator 7y ago> In Docker Swarm, that's a Stack. K8s has no equivalent. My take is that the equivalent in k8s is it's declarative management with configuration files. Just kubectl apply -f your.yaml and you're good to go.
- chuhnk 7y agoWe've been working on something similar for a few years now. Micro is a runtime for microservices https://github.com/micro/micro https://github.com/micro/micro. We primarily focused on Go and are moving towards multilanguage via a http api, proxy and SDKs much like dapr.
- sheeshkebab 7y agoTrying to manage an “application” in microservices world is misunderstanding the whole concept of microservices, IMO.
- vturecek 7y agoInterestingly, what we found through our research was that nobody could agree on a definition of "application" in a microservices world. The way OAM is designed currently doesn't enforce a rigid "application" structure for services. We have a concept of application scopes that can be used to place application-like boundaries around groups of services (modeled as "components" in OAM). For example, grouping services in a "health" scope where the health of each service in the group is evaluated when any one of the services is upgraded as a trigger for automated rollback is something application scopes are designed for. disclosure: am one of the OAM authors.
- yodon 7y agoHow does Dapr (or the Actors in Dapr) relate to Microsoft Orleans?
- mwjfussell 7y agoMarkF from Azure team. The actors in Dapr are based on the same virtual actor concept that Orleans has, meaning that they are activated when called and eventually garbage collected. If you are familiar with Orleans, Dapr actors will be familiar. The difference with Dapr is that because it is programming language agnostic with an http/gRPC API the actors can be called from any language (although there are also friendly language SDKs on top). Creating a new actor follows a local call like http://localhost:3500/v1.0/actors/<actorType>/<actorId>/method/<method> http://localhost:3500/v1.0/actors/<actorType>/<actorId>/meth... for example http://localhost:3500/v1.0/actors/myactor/50/method/getData http://localhost:3500/v1.0/actors/myactor/50/method/getData to call the getData method on myactor with id=50
- ryuukk_ 7y agolooking at how they manage windows update and all their app ecosystem including their store i wouldn't want to trust them, they are the kings of the enterprise bloatware
- ryuukk_ 7y agoit is Alibaba + Microsoft, not just MS https://www.alibabacloud.com/blog/announcing-the-open-application-model-oam-an-open-standard-for-developing-and-operating-applications-on-kubernetes-and-other-platforms_595450 https://www.alibabacloud.com/blog/announcing-the-open-applic...
- ArtWomb 7y agoWorry about vendor lock-in is real. 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. In the early days of Cloud technologies, the original vision was highly commoditized. You'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.
- geggam 7y agoAll of this is well and good. Now find folks who understand the entire stack and can support it. Tell me you are saving money after you hire them :)
- dajohnson89 7y agoI really don't understand how this point isn't more widely acknowledged. k8 expertise is expensive. I'm seeing companies jump in head-first without doing any cost-benefit analysis, and winding up in some really difficult situations.
- Bombthecat 7y agoFirst mover advantage. And when the recession hits you fire them and your pipeline should be mostly automated by then... The rest is still paying full monolithic big servers. And slow deployments.
- geggam 7y agoThat only works until your first outage :) K8s isnt bulletproof and requires significant care. Not to mention constant upgrades
- markbnj 7y agoThe bit about significant care may be true in on-prem installations, I don't know, but GKE for example is pretty darn bulletproof. As for upgrades, they do come along frequently and you don't want to get too far behind. Rolling nodepools has made the process a lot less labor and time intensive for us.
- geggam 7y agoFrom my perspective using GKE or any other k8s service isn't you running k8s. It's you paying devops salaries to release managers.
- lnsp 7y agoSomehow 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's still pretty decent compared to all the other projects in the ecosystem (looking at OpenShift, Istio ...). I really don'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. 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.
- derefr 7y agoFundamentally, k8s isn’t a compute job scheduler—it’s an IaaS state converger, like Terraform, or AWS CloudFormation. As such, it needs to know how to model—and manipulate—the state of pretty much any IaaS resource you have. (And, unlike alternatives, it’s also extensible with custom convergible resource types, too.) That doesn’t mean that k8s itself is all that complex. It just needs a lot of libraries for all the stuff you might do with it, where any given library will be dead code to 99% of people; and an architecture flexible enough to allow it to drive and track the state of those libraries.
- jacques_chester 7y agoI think Kubernetes-the-scheduler and Kubernetes-the-patterns-with-reified-examples have diverged and are going to continue diverging. The latter is more of a microkernel for distributed control systems. My hunch is that this means OAM may be dead letter in the long run. Abstract from Kubernetes-as-scheduler, fine and good. But Kubernetes-as-microkernel is close to doing that already. Whatever my gripes about the details, the mechanisms and affordances are consistent and predictable. That's very valuable.
- the_duke 7y agoKeeping different perspectives and roles in mind is important here. I think the quotes in the article make very good points. I've introduced Kubernetes at multiple companies , usually with good results. But Kubernetes is a relatively low level runtime. It requires a lot of knowledge if you want to use it correctly, even with hosted Kubernetes offerings. Application developers want to specify how the application works without having to learn a whole lot about Kubernetes internals. They also want the freedom to run something on different platforms without a lot of changes. Think Elastic Beanstalk or Google App Engine, but provider independent. With the freedom to run it locally , maybe on a cheap self hosted cluster for dev deployments and on AWS for production. This is a lot of work right now, even with the hosted Kubernetes offerings. Also enterprises often want to offload the decision making and rely both on common standard solutions and outside support if things happen. This is hard with k8s due to the flexibility of the platform. I agree that it is too low level and too complex to provide a good company wide foundation on its own. OAM could be a very valuable tool to have. Also the points about Dapr resonant e. Building a complex event driven architecture with many services is what a lot of enterprises want , but it is really hard to do it well. There is a similar effort by IBM , but I don't remember the name right now.
- gabrtv 7y agoGabe here from the Azure team. Happy to answer questions about Dapr and OAM.
- bjt 7y agoThis is exciting! 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. (https://www.12factor.net/ https://www.12factor.net/) . It's very encouraging to see that coming back.
- gabrtv 7y agoGabe from the Azure team here. I’m also the guy who founded Deis ;) Glad you like what you see. The original Deis team worked on much of it. I’m happy to say we have a lot more innovation coming in the PaaS space.
- devkulkarni 7y agoReferring to Microsoft's original announcement post of OAM, (https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-open-application-model/ https://cloudblogs.microsoft.com/opensource/2019/10/16/annou...), 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. 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 (https://cloudblogs.microsoft.com/opensource/2018/12/04/announcing-cnab-cloud-agnostic-format-packaging-running-distributed-applications/ https://cloudblogs.microsoft.com/opensource/2018/12/04/annou...). Here is what we have learnt about this space in the last one and a half years. 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 (https://github.com/cloud-ark/kubeplus https://github.com/cloud-ark/kubeplus). Check out this blog post which provides detailed comparison between existing tools. https://medium.com/@cloudark/discovery-and-binding-of-kubernetes-custom-resources-in-multi-operator-environments-b5acf88fa639 https://medium.com/@cloudark/discovery-and-binding-of-kubern... On separation of concern between Devs & 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 & Ops. In our view the goal for anyone developing new tools/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 - https://cloudark.io/platform-as-code https://cloudark.io/platform-as-code