The demise of Docker and the rise of Kubernetes

The real world is still very much using Docker. Infact a few companies I&#x27;ve interviewed with this year aren&#x27;t even using any kind of container setup and they&#x27;re doing just fine and making money.<p>This kind of article just adds to the Jonesing-for-shiny-things mentality that really doesn&#x27;t do the engineering world any favours.

&gt; If you’re (only) a docker expert, you’re in troubles right now. There are no more jobs looking for docker expertise and you’re dangerously close to unemployable.<p>This is such a silly and unrealistic argument - no one is a docker-only expert. And docker <i>is</i> a desirable skill, just not on its own. It&#x27;s like saying that git-only experts are unemployable.

&gt; If you’re (only) a docker expert, you’re in troubles right now. There are no more jobs looking for docker expertise and you’re dangerously close to unemployable.<p>&gt; Kubernetes has succeeded where docker failed. Management buy-in.<p>This must be one of the silliest articles I&#x27;ve read in a long time. Computer science and engineering does not revolve around the latest devops flavour du-jour. It will be something else in three years time anyway.<p>The real innovation around Docker was taking existing building blocks which were not straightforward to use on their own (linux cgroups, overlayfs) and bringing them under a cohesive package that&#x27;s accessible to any developer.

And yet I still have to deploy my first Kubernetes setup and have used Docker multiple times ...<p>Is there some kind of &quot;Kubernetes-light&quot; out there? So something like in-between running services like NGinx and Postgres on bare Linux machines and having this (I think complex) Kubernetes setup? It&#x27;s important to say that I don&#x27;t need any scaling capabilities (apart from maybe some load-balancing in case of a machine error).

This type of propaganda is an insult to human intelligence. What, the author is hoping that the readers underwent a lobotomy?

Docker is still pretty embedded in a lot of workflows, thanks in part to its use by-default in many Kubernetes distributions, and the popularity of Docker Hub - not to mention various tutorials and scripts which refer to docker tooling.<p>But yep, I&#x27;d agree with the general premise here - with the emergence of tools like cri-o[0], podman and buildah (which let you build and ship container images without the need to run a background daemon like docker at all, avoiding the associated operational&#x2F;security&#x2F;system overheads) - docker may need to evolve or it&#x27;ll quickly become less favourable.<p>Project Atomic[1] runs a good PPA with many of these packages for anyone interested and using Ubuntu.<p>[0] <a href="https:&#x2F;&#x2F;cri-o.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cri-o.io&#x2F;</a><p>[1] <a href="http:&#x2F;&#x2F;www.projectatomic.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.projectatomic.io&#x2F;</a>

A badly written, rambling article that seems to provide no insight and declares Docker dead because k8s is the flavour of the month. I felt stupider the longer I read on.

Docker has not built support for cgroups v2 - which has been available in linux for 3 years. <a href="https:&#x2F;&#x2F;github.com&#x2F;opencontainers&#x2F;runc&#x2F;issues&#x2F;654" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;opencontainers&#x2F;runc&#x2F;issues&#x2F;654</a><p>in order to force this issue, Fedora has made cgroups v2 as default and mandatory in the new upcoming Fedora 31 causing docker to fail to run. <a href="https:&#x2F;&#x2F;github.com&#x2F;docker&#x2F;for-linux&#x2F;issues&#x2F;665" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;docker&#x2F;for-linux&#x2F;issues&#x2F;665</a><p>Podman (and other docker equivalents) have supported cgroups v2 for years.<p>I suspect that k8s will move away from docker to recommending one of the alternatives pretty soon.

Me not using any of them, still doing old style on-premises deployments, VM based.<p>I bet in about 5 years time we will be reading a similar article about Kubernetes.

For 99.9% of the uses, k8s is a cannon, while the problem you&#x27;re trying to solve is a fly.<p>Use the right tool for the job, please. Trying to force something, just because it&#x27;s thw buzzword of the day, will only waste money and bring suffering.

Kubernetes is a thick, complex wrapper around deploying Docker applications.

I&#x27;m not particularly fond of Docker but I don&#x27;t see it going away any time soon. I acknowledge there has been alternatives around which were better in some aspects than Docker yet haven&#x27;t worked in a single company that didn&#x27;t use Docker with Kubernetes or other orchestrators (e.g. AWS ECS). Not saying they don&#x27;t exist, but it&#x27;s very rare on my experience (both as fte and as a consultant).<p>Also I have never met a dedicated &quot;docker expert&quot; as the article calls it. I mean, is there any company out there who&#x27;s hiring people that <i>only knows Docker</i>? Does that make any sense?<p>Docker may get replaced by alternatives as they start getting more traction over time but I don&#x27;t think this will happen all of the sudden - Docker is still relevant for good or for bad.

They should have accepted the buy out offer when they had a chance, but were arrogant and insisted that their valuation should be greater than VMWare at the time. Of course this never really made much sense if you understand the behind-the-scenes tech Docker uses.<p>This is a great precautionary tale to founders and an awesome example of hubris at play.<p>Docker&#x27;s biggest problem was that they provided tremendous value with their opensource product, leaving few to have any justifiable reason to pay them money.<p>They courted Riot Games for years, until finally they flat out told them they would never see a penny from them. There are many things that can be learned from a business perspective here...

The best reason to use Kubernetes (and in many cases the only reason) is to boost your employability.<p>It gets harder and harder to find a stack that doesn&#x27;t rely on it.<p>At my company, we chose to use ECS&#x2F;Fargate when possible. It integrates nicely with SSM Parameter Store for config and secrets, and has a simple service discovery feature based on DNS.<p>A few services run on EC2 + ASG, using AMIs build with Ansible and Packer.<p>Are we missing something by not using Kubernetes? Is the experience so amazing, compared to ECS? I don&#x27;t care about vendor lock-in.

This article just sort of meanders without going anywhere or providing any insight. Certainly no new insight. Docker the company didn’t manage to solve the right problems in time. K8s hype is through the roof.<p>But the irony is that the Docker infrastructure is a critical dependency for the vast majority of K8s users. And if it falls apart, a lot of stuff is going to break. I hope someone has some contingency plans for Docker Hub going away.

This article makes the classic assumption that deployment of web services is the entire world.<p>We use docker as part of our CI, because that&#x27;s what Gitlab uses for our CI system. It works very well. Of course we could use podman locally (and I do on some machines), but Gitlab will still be using docker for us.

On a side note most of these systems use YAML and as a dyslexic i really have a hard time spotting indenting issues and issues where i should have been using lists. Getting an ide with support for it doesn&#x27;t make it better.

This is like saying &quot;The demise of Wheels and the rise of Automobiles&quot;

I think that Kubernetes can run with CRI-O as the container engine instead of docker, with a nice performance increase since docker is more than just a simple runtime. Iirc it even has slots ...

Well my firm, a F200 organization, is going with Docker. We looked at Pivotal Cloud Foundry and Red Hat OpenShift and chose Docker. Why? For one it&#x27;s cheaper but the killer was with Docker EE 3.0 we get Kubernetes and Swarm. We have vendors who are now deploying software to us using Docker and some are using Swarm and some are using Kubernetes. With Docker we get the best of both worlds. So it may be a bit too early to go ringing the &#x27;Docker is Dead&#x27; bell.

Coming from someone who only uses docker for development purposes, Kubernetes feels like an overly complicated solution for a problem that 1% of development teams need.

Docker is too simple and limited to make a living off it

thehftguy sometimes has very good articles, but it&#x27;s obvious he doesn&#x27;t know&#x2F;understand much about the container landscape. He would be correct if he said, &quot;The demise of Docker swarm and rise of Kubernetes&quot;<p>For those that don&#x27;t know, Kubernetes is a container orchestrator. That means when you have lots of containers, hundreds or thousands and lots of servers to run them on. Instead of wiring them manually and deploying them manually, kubernetes make&#x27;s it easy. kubernetes will decide which server to run them on and wire them together, if a server goes down, it will restart the down containers on new servers provided you have the capacity.<p>Imagine that docker is a computer program, kubernetes is the operating system.

Docker swarm never really took off.

&gt; If you’ve run a “apt-get install mysql” in the past decade, high chances it setup MariaDB instead, getting aliased and substituted transparently.<p>Is that true on Ubuntu&#x2F;Debian? I couldn&#x27;t find a source for this.

kube will die before docker. kube is not fun. VMware should buy docker. We should write a much better container orchestration platform with layer 7 in mind and multi regional availability.

What are you using to build your images for kubernetes?

Don&#x27;t most people use both together?