Microsoft launches new open-source projects around Kubernetes and microservices

https://techcrunch.com/2019/10/16/microsoft-launches-new-open-source-projects-around-kubernetes-and-microservices/

by bastichelaar • 7 years ago

223 124 7 years ago

andy_ppp• 7 years ago

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.

gabrtv13• 7 years ago

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

mwjfussell4• 7 years ago

MarkF 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.

markbnj5• 7 years ago

I 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• 7 years ago

Yes. 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.

sheeshkebab2• 7 years ago

I think they meant get near editing Kubernetes yaml files (or some abstracted equivalent there of)

rumanator4• 7 years ago

Here's a link to the Open Application Model spec.

https://openappmodel.io/

markbnj5• 7 years ago

Thanks!

ubercow• 7 years ago

Maybe a better link: https://cloudblogs.microsoft.com/opensource/2019/10/16/annou...

and to the GitHub projects themselves https://openappmodel.io/

https://github.com/oam-dev/spec/ https://github.com/oam-dev/rudr/

hardwaresofton• 7 years ago

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

gabrtv13• 7 years ago

Gabe 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.

mwjfussell4• 7 years ago

MarkF 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.

jeethsuresh4• 7 years ago

Dapr 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/annou...

gabrtv13• 7 years 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.

jeethsuresh4• 7 years ago

Virtual Server Instances - VMs :)

vturecek3• 7 years ago

The 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.

jeethsuresh4• 7 years ago

Interesting - if you don't mind indulging me a little, it was surprising to me that you chose kubernetes as the first implementation for this standard. After all, if a large part of OAM's functionality is provided by k8s out of the box (auto-scaling, for example) it's not very useful to someone who knows the existing tech. Kubernetes is, by and large, already portable with minimal dev resources between the major cloud vendors and/or on-prem resources.

On the other hand, if you can pair already-written software with a collection of VMs and place an OAM layer between the machines and business logic, the portability of your code between OAM-compatible vendors becomes a selling point for the standard. I know a large project like this is a team effort, but can you shed any light on the reasons behind your decision-making and prioritization towards kubernetes?

williamallthing• 7 years ago

Dapr is definitely not Microsoft's answer to Istio (see e.g. [1]). But if you are looking for something like Istio but that actually works out of the box (zero config), I'd highly recommend checking out Linkerd.

[1] https://news.ycombinator.com/item?id=21283956

jeethsuresh4• 7 years ago

Good to know - I haven't been keeping up with this thread.

I'll have to check out linkerd, thanks for the rec!

mweibel2• 7 years ago

  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.

This statement sounds very backwards to me. Isn't this increasing the separation between devs and ops which we want to get rid of?

latchkey2• 7 years ago

I 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.

gabrtv13• 7 years ago

Gabe 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.

Lutger• 7 years ago

Agree. 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.

gabrtv13• 7 years ago

Gabe from the Azure team here. The goal of OAM is to promote better layering of the development and operations functions inside any org. This is modeled from what we’ve learned about high-functioning teams operating Kubernetes at scale, plus what we’ve learned running services inside Microsoft.

The desire to have software engineers focus only on business logic is strong. This tends to result in the creation of an internal “platform team” that provides services to dev teams. Effectively an internal PaaS.

OAM helps enable this pattern.

tikkabhuna• 7 years ago

As he mentions marketplace, maybe he's talking about product developers and ops teams in other organisations? Elastic, for example, publish an OAM that helps X organisation to get started and they can customise the implementation?

gabrtv13• 7 years ago

Gabe from the Azure team here.

Yes that is what Mark meant. At Microsoft we care deeply about empowering ISVs — we always have. OAM is designed to allow components from an ISV to be bound to a runtime environment by a separate consumer, where the concept of traits can provide configurability for things like ingress, autoscaling, secrets management, etc.

Dev_2019• 7 years ago

As a developer I don't want to touch ops. So "we" does not exist.

klodolph8• 7 years ago

Like… you don’t want to talk to the ops team at all? You don’t want them to talk to you?

(Also… in English, “we” does not always include the listener. Whether the listener is included is unspecified.)

ownagefool4• 7 years ago

I think the idea that a Ops needs to wake up in the middle of the night to deal with shit outages because a developer is unwilling to stand behind their code is probably outdated.

Build & Run is becoming very popular.

mweibel2• 7 years ago

"we" doesn't necessarily include all.

Anyway, that's a bit sad IMHO. In my opinion, running what you build is great to discover ways to improve your software.

Regardless if you want to or don't want to touch ops: You still might want to talk to ops or vice-versa. Even if you have strict roles for devs and ops (and no mixed roles), you might be in a team where both are present and hopefully talk to each other.

SideburnsOfDoom2• 7 years ago

The truth of what the code that you develop actually does, is in production; often buried in log stores and timing stats and other "ops" places.

It's better if that data is unearthed and fed back into the development process, it's better if that feedback loop is closed, it's better if that separation is removed.

That's one of the reasons for "DevOps" as originally formulated.

skywhopper3• 7 years ago

Well, as an ops person, I don't want to touch your code, then.

gabrtv13• 7 years ago

Gabe from the Azure team here.

We built OAM for you, and for your counterparts in ops who want to help you innovate faster. :)

ownagefool4• 7 years ago

This isn't the problem that kubernetes solves, and pretty much every bank or big org I've been involved with have little fiefdoms fighting against teamwork... err I mean DevOps.

dfcowell• 7 years ago

In finance at least, there are often regulators that get in the way. For example, in my current company, we’d love to support our anemic Ops team, however a developer having any kind of influence on the deployment process is strictly forbidden by our regulator.

klodolph8• 7 years ago

Not only that, but YAML as configuration has some pretty significant drawbacks in that the natural (but disastrous) trend is towards using text templating systems to generate YAML files. It’s also a bit difficult to parse or write correctly.

Yes, you “shouldn’t” use text templating systems for YAML and you “should” use well-tested YAML parsers and emitters. But I am very skeptical here, especially given that this wonky format is supposed to be the interface between teams that aren’t talking to each other.

baq3• 7 years ago

i honestly have trouble understanding the love for yaml when decades ago everything was xml and it was almost universally hated. technically you can define a yaml-xml isomorphism and as a consequence they both should be treated as unsuitable, and yet... yaml somehow is cool and xml isn't.

am i just old?

gabrtv13• 7 years ago

Gabe from the Azure team.

+1 on YAML having its fair share of problems. I like to think of them as our collective problems, since nothing has emerged to replace YAML yet. If something does I’m certain OAM could be adapted to it.

I’ve personally seen some promising exploration of config through Turing-complete languages like TypeScript. See Pulumi.

tracker13• 7 years ago

With a text editor that understands YAML, I have yet to see a significantly better option for software configuration files. TOML is a decent option as well.

jacques_chester7• 7 years ago

This statement sounds very backwards to me. Isn't this increasing the separation between devs and ops which we want to get rid of?

I think the answer is that this can't be settled once and for all, because there are economies from specialisation and diseconomies from coordination.

My general view these days is that for a sufficiently large org, you will inevitably have a degree of separation between application engineering and platform engineering. What's important is to establish relatively clear contracts between them which avoids unnecessary complexity and delay being transmitted across the Conway boundary.

Good interfaces and technical contracts between the roles make this a lot easier. It used to be that getting something up and running was difficult because the incidence of cost and control fell on opposite sides more than once. For example: As a Dev, I need a place to run my software (cost). But someone else needs to provision and install it (control). Or: as an Operator, I don't want to be paged at 3am (cost). But someone else wrote the app (control).

When you draw the boundaries so that devs get self-service and ops get to (mostly) ignore what's inside the self-service boxes, a lot of this tension largely vanishes. That's not so much about whether folks sit in the same team and more about using technology to dissolve the tensions altogether.

Disclosure: I work for Pivotal, we have been known to dabble in this sort of thing.

gabrtv13• 7 years ago

Well said, Jacques.

hiccuphippo• 7 years ago

Wouldn't this be because they want the ops team to be Azure and don't want the developer to talk to customer support?

derefr2• 7 years ago

You’re thinking of the separation between devs and ops at the same company. I think the text you’re quoting is talking about the separation between third-party vendors’ devs, and first-party downstream ops people.

And it’s never been a goal, to disintermediate ops people from other companies’ devs. We’ve been doing just the opposite for ages, with things like VM “appliances” and Docker images, created so that the interface between “the devs at the company that created this” and “the ops people deploying it” can be more formally defined by some kind of deployment-time configuration API. This is another case of that.

gabrtv13• 7 years ago

Gabe from the Azure team here. We do want to promote more separation between dev and ops. Taking on too much conceptual overhead is hard for any engineer. By having developers focus on business logic and operators focus on platform concerns, both can be more productive.

markbnj5• 7 years ago

There is a whole layer of on-prem care and feeding of kubernetes with which I have no experience (having run workloads on GKE for four years), and it certainly makes sense that there is some specialization of that stuff and separation between the people who implement those things and the people who develop back end apps.

But I balk at the idea that there is a general good to be had from further separating dev and ops. Isn't the whole point of kubernetes to provide useful control abstractions over the complexities involved in deploying components on the back end? You seem to be implying that once an engineer has developed a thing it needs to be tossed over a wall so that a specialist can write the k8s manifests, determine the runtime resource requirements, provision ingress, etc. Maybe that general approach is necessary in the enterprise environments which seem to be Azure's primary target market, I don't know. But I do know that on our much smaller team the back end engineers have become thoroughly comfortable with performing those tasks for their own applications with a little assist here and there from devops. Most of them never have to touch kubectl because deployment to test and production environments is handled by ci/cd pipelines, so really their concerns are focused on writing proper manifests to create the environment their thing needs. I don't think that is too complex a task for someone whose daily job is writing back-end server components.

malkia• 7 years ago

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

jmcomets• 7 years ago

I 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?

rumanator4• 7 years ago

On 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

orthoxerox• 7 years ago

At 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.

rumanator4• 7 years ago

Links to related discussions:

* Dapr: an open-source project to make it easier to build microservices: https://news.ycombinator.com/item?id=21272098

* Announcing the Open Application Model (OAM):

https://news.ycombinator.com/item?id=21272082

Havoc2• 7 years ago

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

mwjfussell4• 7 years ago

MarkF 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

Havoc2• 7 years 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_• 7 years ago

I think Microsoft is becoming an open-source company!

aairey3• 7 years ago

That's what they want you to think!

steego• 7 years ago

They have to become an open source company because they can't risk putting all their eggs in the software basket.

They have to work on projects like this to ensure developers can easily deploy to Azure so they can hedge their revenue.

sandGorgon2• 7 years ago

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.

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• 7 years ago

Actually, Docker can now deploy stacks as a k8s “stack” resource: https://www.docker.com/blog/simplifying-kubernetes-with-dock...

This makes it especially easy for anyone transitioning from Docker Swarm to Kubernetes.

sandGorgon2• 7 years ago

True. 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.

fogetti• 7 years ago

Thanks for the link. I haven't heard about this before but it seems really useful.

rumanator4• 7 years 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.

whazor• 7 years ago

Ideally yes, however in practice a template engine is nice.

ones_and_zeros• 7 years ago

I don't think there is anything stopping you from bundling multiple services/deployments in the same helm chart. Many of the "curated" helm charts do it: https://github.com/helm/charts

chuhnk• 7 years ago

We've been working on something similar for a few years now. Micro is a runtime for microservices 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.

sheeshkebab2• 7 years ago

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

vturecek3• 7 years ago

Interestingly, 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• 7 years ago

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

mwjfussell4• 7 years ago

MarkF 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>/meth...

for example http://localhost:3500/v1.0/actors/myactor/50/method/getData to call the getData method on myactor with id=50

ArtWomb• 7 years ago

Worry 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.

geggam3• 7 years ago

All 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• 7 years ago

I 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• 7 years ago

First 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.

lnsp• 7 years ago

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'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.

dilyevsky• 7 years ago

The one of the main design ideas behind the original Borg system [...] was utilisation of resources and simplicity.

Utilization - yes, simplicity - no. Kubernetes is paragon of beautiful and concise design compared to Borg especially if you get into cluster management side of things.

The complexity that you see comes from unifying compute, networking, storage and now even cluster management under single bundle of APIs. Borg never did that on my watch and openshift did this in a way more complex way.

derefr2• 7 years ago

Fundamentally, 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_chester7• 7 years ago

I 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.

mfer• 7 years ago

If you print the Kubernetes API (only the latest stable parts) for what you'd need to workloads to PDF as 8.5x11 (~A4) you'll get over 1,100 pages. This is for the descriptions of all the objects in the API you work with. The manifests.

This doesn't include practical or useful documentation on them and doesn't cover CRDs (like what Istio provides).

The amount of complexity someone has to learn to use Kubernetes is large and growing.

I really like the idea of systems to simplify the learning curve and onboarding.

jacques_chester7• 7 years ago

just look at the LOC of kube-api

A fair amount of bulk rests at the feet of Golang, not Kubernetes per se. Vast sweeping vistas of Kubernetes code is generated from a handful of files because generics are silly and code generation is just swell.

gabrtv13• 7 years ago

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

bjt• 7 years ago

This 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/) . It's very encouraging to see that coming back.

gabrtv13• 7 years ago

Gabe 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• 7 years ago

Referring to Microsoft's original announcement post of OAM, (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/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). Check out this blog post which provides detailed comparison between existing tools. 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

Microsoft launches new open-source projects around Kubernetes and microservices

Related Stories