Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft launches new open-source projects around Kubernetes and microservices

techcrunch.com

Post reply on HN
Print view View original

71–80 of 129 posts

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

#71

Post by geggam »

Bombthecat wrote: post #69
dajohnson89 wrote: post #68

Earlier quoted context omitted.

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.

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

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

#72

Post by eropple »

klodolph wrote: post #37
mrweasel wrote: post #27

Earlier quoted context omitted.

We're reaching a point where two groups of people, rather than one, is required to wake up in the middle of the night. Previously just the operations people needed to get up, now developers need to be on-call as well. Operations teams are scaling down their monitoring to just infrastructure, because the applications are more opaque than ever. Incidents at the application level are no longer fixable by Ops, because th…

I would say that the problem in this situation is hard to avoid. If you can have an operations team who are experts on the application as well, and have the team more closely integrated with the development team, then you generally don’t need to wake up developers at night. I spent a few years on a team set up like this and it worked very well. If your project isn’t big enough for its own operation team you can share…

> If you can have an operations team who are experts on the application as well

Then functionally they're going to end up as software developers. And you're going to treat them as such or they're going to leave. Which is what the notion of a "devops engineer" evolved to be, yet every good-to-great "devops engineer" I've ever worked with identified as a software developer and could be hired at any developer role they wanted.

If you want a warm-body ops team, they're not going to be experts. If you want experts, in 2019 they're going to rapidly stop being just-an-ops-team.

> Some managers have told me that hiring for devops is harder.

It's easier to hire "devops" if your idea of "devops" is "somebody with an AWS Associate cert." It's much harder to hire "devops" if your idea of "devops" is "thinks systematically and is capable of debugging a problem nose-to-tail without waking up a developer."

I am the latter, and there are remarkably few of these.

> And developers should feel some of the pain—I’m not saying page them in the middle of the night, but they should be doing daytime on-call rotations.

I feel like you've got this wildly backwards. Developers should be first-line on-call in almost every situation modulo detectible hardware failures. Because here's the thing--I've been doing this a long time as a mostly-unbiased consultant (I'm in-house now and it still holds), and in most environments, operations/infrastructure 1) break things less, and 2) break things quickly, so there's usually relatively little time between the break and the working-hours fix.

If a developer can't solve a developer problem because they think it's actually infrastructural, they can escalate. Making that ops/infra group be first-line support for application pages is both inefficient and unfair.

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

#73

Post by dilyevsky »

lnsp wrote: 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…

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

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

#74

Post by fogetti »

blairhudson wrote: post #31
sandGorgon wrote: post #28

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"

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.

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

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

#75

Post by derefr »

lnsp wrote: 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…

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.

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

#76

Post by derefr »

mweibel wrote: 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…

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.

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

#77

Post by klodolph »

skywhopper wrote: post #57
klodolph wrote: post #35

Earlier quoted context omitted.

I used to think YAML was friendly for humans to read. Then I wrote a parser for it, and discovered all the weird corners, edge cases, etc. I now consider it to be a fairly user-hostile format, which should be avoided in favor of just about everything else (XML, JSON, TOML, text protobuf, etc are all more friendly). For example, consider this map of regions in YAML: regions: northamerica: [ca, us, mx] scandinavia: [dk…

Curious if you wrote parsers for the other languages you claim are easier. YAML has problem areas, particularly around implicit booleans, but languages without any comment syntax (ie JSON) can not be considered human-friendly. And XML is not even the same sort of language as the rest of these. I understand thinking YAML makes the wrong tradeoffs, but if you think it's less friendly than XML, then you haven't really w…

> Curious if you wrote parsers for the other languages you claim are easier.

Yes. YAML was a damn mess compared to the others. You can get a rough estimate of how much by looking at the size of the specs—the XML spec is a fair bit shorter than YAML’s, and if you drop the part about DTDs (which are used less these days) the difference is even bigger. The TOML spec is far, far shorter than either one and the JSON spec makes the TOML spec look big.

I write a lot of parsers. I think it’s fun.

> …but if you think it's less friendly than XML, then you haven't really worked with XML.

If you want to talk about formats, let’s talk about formats. If you make claims that I must be inexperienced because I disagree with you, then it’s just rude.

I have done a few reasonable size projects with heavy XML use. A build system, some work with RPCs, and a web app where I wrote a ton of data for it in XML format, by hand. I also wrote an XML pretty-printer and a YAML pretty-printer. I did a conversion of the XML build system to YAML. I thought it was a bad tradeoff, so I reverted it. Since then I’ve migrated to Bazel. All this experience is a mix of hobby projects and professional.

The bad for XML—it’s more verbose. You have to decide on your own mapping between XML and data. That’s it, as far as I’m concerned.

My personal sense of it is YAML is in a pretty awkward place—it only makes sense for human authoring, not data exchange. My experience with it is that people will naturally want to automatically generate things that they would otherwise have to write by hand. So if you draw a Venn diagram, the YAML use cases are “human authored but not machine generated”.

If we think of using these formats for configuration, then the BIG problem is the sliding scale between pure-data approaches to configuration and using code for configuration. As systems mature and get more complex, the configs often acquire features of programming languages, or parts of the config gets rewritten in code. This is where YAML really suffers. XML is a bit easier, either to extend to add these kind of features or to emit from code.

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

#79

Post by markbnj »

rumanator wrote: post #17
markbnj wrote: post #3

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

Here's a link to the Open Application Model spec. https://openappmodel.io/

Thanks!

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

#80

Post by steego »

aairey wrote: post #49
naveen_ wrote: post #20

I think Microsoft is becoming an open-source company!

That's what they want you to think!

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.

Post reply on HN