The Kleenex effect

Back in January 2014, I was invited to Finland to host a lecture and workshop on software containers.
At the time, the software container concept was fairly new, so getting the attention of the audience wasn’t very challenging. In any case, it was easier than waking up the day after: Team Belgium might have overestimated their thirst a little.

Docker wasn’t yet very mature and was still in the 0.x release branch, but it already had the merit of bringing the container concept to the mass.
Great documentation, a decent CLI, strong partnerships and clever marketing were the ingredients of the success story.

My job to explain things was straightforward: there was Docker, Docker and Docker, and only if you really wanted to dig deeper, you also needed to explain it was built on LXC.
That last part was only temporarily: Docker ditched LXC for their own underlying runtime (libcontainer) the year after. (v0.9).

Ever since, Docker conquered the world of software containers. Competitors (Mesos, rkt, ..) were left with only some crumbles with their own implementations, and they always stayed somewhat in the shadow of Moby, the Fat Blue Whale.
In those years, Docker started showing off the ‘Kleenex’-effect: the trademark became the product.

One of the big achievements of the Docker crew was that they helped to create a standard package format and runtime for containers in the Open Container Initiative. Basically, they donated the libcontainer low-level runtime (renamed to runc) and their image format (renamed to OCI image).

Although the importance of this move can not be overestimated, it was also the beginning of the end of the Docker supremacy.

The king is dead, long live the king!

Houston, we have a standard

With those standards in place, competing products had one problem less in their struggle for relevance. The result is a vibrant ecosystem where new players and initiatives are announced on an almost weekly basis. Have a look at the cloud native landscape to understand what I mean..

For example, Red Hat is pushing hard to get their own high level runtime implemented across the board. Podman is now the default way to deploy a container in RHEL8 and Openshift 4. It uses the same standardised OCI container image format, and the same OCI low-level runtime (runc), but it tries to relieve us sysadmins from some serieus Docker limitations with new high-level runtime implementations:

With Podman (and Buildah):

  • the same ‘Docker’-images can be used because the image format and low-level runtime are unchanged and OCI compliant
  • there is no central daemon: no more containerd as single point of failure on the container host
  • rootless containers are possible resulting in a smaller attack surface

Docker vs Podman

The new reality

Another reason Docker gathered fame is because they host the well known container registry: https://hub.docker.com.

But the reputation of this public repository & de facto place to look for official containers is fainting. The decision to implement rate-limiting last November will for sure frustrate some users.
Eventually, the limit will be set to 100 pulls per six hours for free accounts. They measure this by looking at your public IP. Although this might seem reasonable at first, if you are using NAT, your colleagues might incidentally break CI/CD pipelines located behind the same public IP address, just because their docker pull executions count against the same counter. Merely a day after this anouncement, multiple key players already announced their alternative.

Is this another step towards the end game of Docker Inc? Now that they ditched their container management platform (Swarm), sold their enterprise unit, became redundant as a runtime (as explained in this article), and have limited the free use of their registry, competitors will be more than happy to fill the gaps.

Also, a few weeks ago, the news broke that as of version 1.20, Kubernetes won’t use Docker anymore as the default high-level container runtime by default. As this is does not implicate a switch of the low-level runtime, you probably shouldn’t care.
But you already knew that, because you just read this post. ;-)

Sources: