Hacker News Reader

Comment by EwanToo | Hacker News Reader

A brave decision, but I think it's the right one for both CoreOS, and in the long-run, their customers.

Definitely pretty painful for people who have already adopted fleet, but a year of support is much better than I would expect

View on HN

I too salute CoreOS for doing the right thing for their customers and the ecosystem. Kubernetes was something that was hard to predict, it didn't grow organically but was suddenly released by Google.

Right now I believe Kubernetes is the project with the most accepted pull requests per day. This came up in a talk from GitHub at Git Merge 2017. It shows that k8s is on its way to becoming the default container scheduler platform. It will be interesting to see how Docker Swarm and Mesosphere will compete during 2017.

The container scheduler is becoming the next server platform. The fifth one after mainframes, minicomputers, microcomputers, and virtual machines.

While configuring GitLab to run on k8s we learned that much of the work (like Helm Charts) doesn't translate to Docker Swarm and Mesosphere. I think there might be strong network effects similar to the Windows operating system.

Might be interesting for the docker runtime in the future as well. That is, assuming k8s spends enough time on supporting alternatives like rkt as well as docker.

Do you think k8s's support for docker and rkt will become the same as the interface becomes standardized with the Open Container Initiative? https://www.opencontainers.org/about

There is currently a ongoing refactoring of the container communication stuff in kubernetes to remove all container engine specific code and just use the Open Container Runtime Interface. This allows any container engine to run with kubernetes as long as they implement the Open Container Runtime Interface.

Completely agreed. The landscape 2-3 years ago looked incredibly different, and I picked Mesos for a rather ambitious project. After it became relatively clear that k8s was going to eclipse Mesos and not by a little bit, trying to unwind that decision basically cost me my job through some political infighting. It's a shame, but such is the price of early adoption, I guess.

Given the same information, I'm really confident that I'd still make both choices the same way.

It could have been worse: You could have tried to run Swarm and k8s on top of Mesos simultaneously.

Hi David, can you reveal some of your environment (e.g. on-prem vs cloud), were there any technical reasons for switching or was it primarily a matter of perception of velocity/popularity between the two projects?

Just to add some of my own perception as someone who works on Mesos, Mesos continues to be popular with large technology companies that don't make their technical investments lightly: Twitter, Apple, Netflix, Uber, Yelp, for example. Companies continue to choose a Mesos stack based on its technical merits. The project is still moving fast and adding powerful primitives to support the needs of production environments while distributions like DC/OS are trying to make Mesos more approachable (easy to install, administer) and comprehensive (providing solutions for load balancing, logging, metrics, etc). I hope you will take another look at the Mesos ecosystem at some point, a lot of care has gone into it :)

Not OP, but I think the perception is that Mesos requires you to roll a lot more of the solution yourself. That's fine if you're a large company who can throw hundreds of developers at your platform, less so if you've got 5 or even 50.

> The fifth one after mainframes, minicomputers, microcomputers, and virtual machines

Interesting though that the last 3 paradigms are largely built on each other. I'm involved in a deployment at the moment which started with buying servers, implementing VMs on them, and finally laying k8s on top of that.

I know most uses of k8s won't ever really see the layers below, but they're still there...

Reply on news.ycombinator.com