Hacker News Reader

Comment by cygned | Hacker News Reader

I had to make a decision for an orchestration tool a few weeks ago and I went with K8s. One of the main reasons was that even Docker advertises it on its website and with Docker for Mac. I expect Swarm support to be canceled in a not so distant future and I cannot rely on a tool with an unclear future.

Which is a pity because I really liked Swarm for its simplicity.

Side note: I am also concerned about Docker in general. CE/EE split, services shutting down, bugs seemingly not being fixed - I cannot point out a precise aspect, but I am concerned.

View on HN

I’m concerned as well. We use Docker and Docker Compose heavily for our development and both on Docker for Windows and Docker for Mac developers have to restart their daemon several times a day. The binaries aren’t open so it’s tough to see and fix the issue; but because we aren’t Docker Enterprise Engine customers, there is no path to support. It would be helpful if there were a way to pay for Docker and receive support without having to go the enterprise route. I can see paying $200 a month for the team for support.

Yikes. Surely Docker is providing you more than $200 worth of value a month. If so, why would you only pay $200?

I might; but that’d have to mean seeing some traction from that money first. They haven’t proven that they’re able to run the sort of business they’re trying to run.

I'm not sure who's going to beat Docker. Docker is central to most orchestration tools so as long as they make money someplace with their central services, they should be fine.

The kubernetes community is pouring a lot of resources into cri-o. I imagine you are going to see the kubernetes clusters that are built 'the hard way' start switching over and removing docker. It will still be used for building pushing containers for the time being.

Kubernetes could move to rkt or even the now standard systemd stuff, end users would hardly know the difference. The container format isn't a very strong lock-in effect and most people are probably better served without the image type format anyway (as the Linux block layer wasn't really constructed with that use case in mind, and fixing the plumbing will take longer time than developing the orchestration tools which is what'll win the users).

Docker the company have few options to monetize on Docker the software when it becomes commoditized. They seeminly chose the Enterprise way, which consists of pretty orchestration tools and integrations with Active Directory. (A perfectly valid option, which worked out well for VMware.) That's a dead end now that Kubernetes won container orchestration. It will be interesting to see where they will go next.

Who’s beating them? Amazon?

Kubernetes had won the container scheduler wars. At GitLab we're all in on making a PaaS based on k8s and our CI/CD and the container registry that is part of GitLab.

It feels awfully 19th century though that despite k8s having "won", by far the biggest container schedulers by containers scheduled are, no doubt:

(I think this is the correct order, not 100% sure of course)

1) google borg (maybe omega) [1]

2) amazon ec2

3) whatever microsoft is using

(large gap)

4) all the rest of the world combined, a small portion of which is k8s

[1] https://www.quora.com/Does-Google-use-the-Open-Source-Kubern...

(one might even say [1] seems to imply it'll never happen, or at least take a very long time. Also if you read the papers it becomes very clear that "Google Borg" includes a lot of things these days at many levels, from custom ASICs, device firmware (as in standard device, google borg firmware), BIOS firmware, entirely custom sub-kernel code, custom kernels, custom userspace (ie. Google-specific libc that's not optional), ... all of these will turn out to have dependencies on eachother that have to be redone for k8s, could take a while to migrate over)

(although I have not read any papers on it (I'd love some though), I'd bet amazon is in a similar boat, and of course Microsoft is Microsoft)

EC2 is not a container scheduler - it's an IaaS for VMs. The Amazon container PaaS (ECS/EKS) is a layer on top of EC2. And that is being superseded by Fargate which will make the underlying EC2 invisible. If you need a Fargate-like capability now, Azure AKS does it.

See https://azure.microsoft.com/en-us/services/container-service... and https://aws.amazon.com/fargate/

So what is the EC2 container scheduler before Fargate called ? Any papers on it ?

ECS and EKS.

Fargate is expensive as hell for long running services. You should only be using it for something that creates value 100% of the time that it is running.

> At GitLab we're all in on making a PaaS based on k8s

This is very interesting. Could you talk more on this ? There is definitely space for an "opinionated k8s distro with batteries included". I have wished for Swarm to become this....

It is not a Kubernetes distribution. You can use any distribution or CaaS you want. The beginning of it is in GitLab Auto DevOps https://about.gitlab.com/2017/10/04/devops-strategy/

Interesting. Is there a blog post where i can read more about this?

https://docs.gitlab.com/ee/topics/autodevops/ and https://about.gitlab.com/2017/10/04/devops-strategy/

Reply on news.ycombinator.com