Live data from Hacker News

Microsoft launches new open-source projects around Kubernetes and microservices

techcrunch.com

81–90 of 129 posts

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#81
post #7

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…

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.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#82
post #70

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…

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.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#83
post #13
post #7

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…

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.

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.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#84
post #7

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…

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 won…

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.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#85
post #71

Earlier quoted context omitted.

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.

That only works until your first outage :) K8s isnt bulletproof and requires significant care. Not to mention constant upgrades

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

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#86
post #7

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…

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.

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.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#87

Earlier quoted context omitted.

I didn’t understand the XML hate either. It was just a bit annoying to parse, depending on the language and ecosystem you used. It was a little verbose, but so what?

The biggest problem to me is that XML is not a data serialization language, it's a document markup language. In documents, the distinction between attributes and content makes sense. In data serialization, the choice of whether a given datum is an attribute or a text content appears rather arbitrary. Should I write this? XML Cookbook Jane Doe Or this? Now attributes don't work when there are multiple values, so I gue…

Thank you for articulating this, but I’m familiar with these complaints. XML does give you a lot of freedom to format your data in different ways, which can get you into traps. I’ve run into those traps before, like the decision between attributes and child nodes.

This doesn’t add up to XML hate, for me. The way I would probably write the document is:

  
    XML Cookbook
    Jane Doe
    Tim Pickens
  
This is a fairly boring way to write out a document and while you can bikeshed all you want, I don’t see the possible bikeshedding as a major drawback. The above is concise and easy to understand.

I wouldn’t use YAML as a basis for comparison. YAML has a fair number of oddities and inconsistencies that led me to stay away from it. XML is at least consistent and simple, there are not really any surprises to speak of and there are plenty of tools for modifying XML documents even when you don’t have the schema. For YAML, although there’s a spec, it’s complicated enough that different implementations are inconsistent with each other and there seems to be some inertia at work here.

There’s also the downright bizarre set of regexes that YAML uses to recognize bare strings as other types, that means that '3.3.0' is a string, but '3.3' is a number. If I write 'ni' that’s a string but 'no' is a boolean. I personally find it harder to read or author YAML due to all these rules. You also have to be a bit more careful to sanitize YAML input due to things like the way !! is handled by various libraries, or the way YAML allows object cycles. It gives you too much rope to hang yourself, has too many surprises, and too many footguns. The fact that YAML is a bit more concise just isn’t enough of an advantage.

    # Quiz: What value does this give you when parsed?
    MAC Address: 11:02:03:04:05:06
For data serialization, I would stick to something like Protocol Buffers. You get a text and binary format, a schema, consistency across implementations, and good tooling.

XML is workable in a lot of situations and in some cases the verbosity makes it a bit more self-documenting than e.g. JSON.

TOML would be my choice for config files that I maintain.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#88
post #7

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…

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

Gabe from the Azure team here.

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

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#89

Earlier quoted context omitted.

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.

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.

Swarm does not have a concept of a stack. This is purely client-side.

Re: Microsoft launches new open-source projects around Kubernetes and microservices

#90
post #2

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 migh…

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

Post reply on HN