[mpermar]

>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level.

I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below.

Kubernetes didn't brought open-source collaboration to a new level. No matter how relevant Kubernetes is today, it's just a drop in the huge ocean of OSS. Maybe level in this context refers to 'gitops' which many of us where doing years before the term was coined and without K8s involved. Or perhaps the author refers to the fact that most gitops K8s frameworks will work via polling which is a fundamental scalability flaw.

[superb-owl]

To try and steelman this line - the CNCF (a major force behind k8s) has indeed been a game-changer for OSS. It has built a way for OSS projects created by large enterprises to move towards vendor-neutral community governance.

IMO the way Kubernetes is built and maintained serves as a model for sustainable, enterprise-grade open source.

[aaronblohowiak]

> It has built a way for OSS projects created by large enterprises to move towards vendor-neutral community governance.

In what way does the cncf do this that the Apache foundation does not?

[morelisp]

I personally can’t wait until we have even more moribund foundations shipping over-engineered corporate leftovers.

[dan-robertson]

The introduction was indeed pretty cheesy. I read it and thought ‘I bet there will be a load of comments about the introduction instead of the article’ and then I read the rest of the article. Thankfully other comments did discuss the real content of the post.

[msoad]

This reads like a buzzword soup to me as well. All of the "ideas" presented are existing systems that author wants them in the source control software. Not sure why?

Also GitHub is the defacto monorepo? Since when you can fork/clone code in a monorepo? The whole point of monorepo is to avoid that!

[skratlo]

Came here to say this, I stopped reading after that, just skimmed the article, it's bunch of horsecrap.

[emn13]

To read this charitably, interpret that statement not to mean that kubernetes-the-software itself is the best gift to OSS collaboration ever, but rather that Kubernetes-the-project "brought open-source collaboration to a new level" in the context of working on kubernetes-the-software. I think that makes more sense, and certainly isn't as pompous.

[jpgvm]

OpenStack had similar levels of contribution at its peak and had much of the same solutions. I'm just guessing the author is newer to the game so might have missed out on 2010-2013 in the infrastructure space.

One of the cool things to come out of it was Zuul, which is a merge queue system similar to Bors and friends.

[damagednoob]

I dunno, the points about UX, merge queue and LFS all ring true for me. All those things are solved outside of Git AFAIK.

[Semiapies]

The rest of the article is just a listicle of wouldn't-it-be-cool-to-haves, so hard for that to have much credibility to start with

[nailer]

Kubernetes main contribution to tech is “let’s do it all using kubernetes” as a meme for wasted time.

It references the effort and money wasted by people that wanted to build cloud providers despite not being in the business of being a cloud provider.

[jpgvm]

Just no.

Kubernetes has it's roots in Omega which was a research project to explore improvements to Borg.

It was created/released as a direct response to increasing lock-in of AWS and Azure PaaS like services that were becoming an existential threat to GCP ever gaining any marketshare.

Unlike OpenStack it did actually manage to mostly achieve it's goal of preventing lock-in by creating a standardized API in which all distributions/managed-providers need to provide and actually certifying that they do. OpenStack failed in this regard because it was overrun by vendor interests too quickly and suffered poor governance. Additionally the leading vendors of the time simply ignored it because none of them offered a compatible API layer and none of them cared about any of the upstarts that did. Also it turned out very few people wanted to build their own IaaS if it would be incompatible with AWS and bursting would be awkward.

k8s successfully learnt from these mistakes.

So it's contributions are two-fold.

1) Single-handedly forced the other 2 major vendors to implement a standard API.

2) Created an infrastructure OSS ecosystem above this API layer that broadly has been successful with enterprise interests while abiding by the governance model set out by core k8s.

These alone make it a very successful project even if you disagree with the technical implementation/merits.

[nailer]

You've said a lot of things but none of these respond to the comment you're referring to.

> 1) Single-handedly forced the other 2 major vendors to implement a standard API.

I (and I'm sure you too, you seem intelligent) would be surprised if say EKS is anywhere close to ECS usage. k8s is considered so complex/poor Amazon sell ECS-on-prem.

It's the epitome of resume driven development - nobody uses k8s for any other reason except to say they use k8s.

[wvh]

What's your alternative for stuff that needs to run on more than one server for reliability or scale? I have been duct-taping HA solutions since the late nineties, it definitely wasn't prettier than Kubernetes. We are beyond the phase where we want to care about a physical server with a broken hard disk or power supply. Whether or not Kubernetes-the-software is the answer to the conceptualisation of a "computer" is beyond the point; there is a clear trend towards abstraction of computing hardware for good reasons, even for companies way smaller than the Googles and AWSes of this world.

[nailer]

> What's your alternative for stuff that needs to run on more than one server for reliability or scale?

Same as most people, and as previously mentioned: I pay pay a cloud provider, unless my business is being a cloud provider.

[0xCAP]

How do you host your stuff on, say, GCP? App engine? Only 1 per project. Compute Engine? Basically a VPS. Cloud Run? Ok, good luck with stuff that requires long running requests or listening to events from a source different from Google Cloud Pub/Sub, because your instances are eventually going to scale down to 0 and not wake up if no HTTP requests are incoming, so basically not an options for microservices if you're rolling with a non-google event broker. Need to host other Kafka, Elastic search, or anything else non-trivially deployable? How do you do that?

[jpgvm]

All of it responds to your original comment which was your statement that it contributed nothing except padded resumes.

I stated several things it contributed -even if you think it's too complex-.

If you don't understand why people use k8s you don't understand the problems it solves. Especially if you think ECS is a substitute.

[nailer]

The thing you stated is that k8s allows people to easily deploy across different cloud providers due to lack of vendor lock in. k8s doesn't because nobody uses it for that - the cost of getting it tunning compared to simpler alternatives removes all value from the cross-platform abilities. That's why k8s is a DevOps meme.