Docker under attack: What motivates Docker’s critics?
Docker has been described as a revelation by some – a technology that allows a sane deployment process that mere lowly, ignorant developers can manage. But it also has its critics. The anti-Docker army has been mobilised and they want everyone to know about it.
A whole range of problems in everyday SysAdmin work for Docker has propelled a few programmers to call for a boycott against it, which went down back in the spring of 2015. A partly controversial debate has seen a varying amount of Docker critics taking the stage. We wanted to ask the question: Where does the anger aimed at Docker come from? And what criticisms are considered justified?
In calling for a boycott, all targets and promises of Docker technology have been taken apart in succession. Technically overvalued, cumbersome to use, especially geared to a veritable provider lock-in – the only advantage of Docker is its popularity according to critics, which at best is simply a marketing vehicle for other projects. We look at some of those criticisms in detail below.
Compared to the use of virtual machines, especially KVM, the authors of the treatise boycotting Docker assume a far worse variability and versatility in use. Docker Images could only run on “docking aided” GNU or Linux systems. The advantage of a lightweight container for computing power would be consumed by a load-rich ecosystem and corresponding network utilisation. SysAdmins working with Docker have been cast down to dwell in deployment hell:
OS running Docker becomes DockerOS. It is not UNIX-like OS. All you default standard commands like ps, ls, find, netstat, sockstat, tail and similar are useless here. You have to learn yet another bunch of new commands with totally different behaviour.
In fact you can not expect to run anything else that is related to network on DockerOS machine.
Forget everything you’ve learned, cry the Docker-boycotters to the SysAdmins of the world. This is because Docker can only be applied with Docker’s own tools and commands, therefore destroying your laboriously created rules for the hierarchies of network interfaces and routing tables. In the same vein, Cal Leeming’s scathing criticism of Docker has caused quite the stir:
If your development workflow is sane, then you will already understand that Docker is unnecessary. All of the features which it claims to be helpful are either useless or poorly implemented, and it’s primary benefits can be easily achieved using namespaces directly. Docker would have been a cute idea 8 years ago, but it’s pretty much useless today.
Also, as far as the network is concerned, Docker isn’t up to date. While boycotters consider the IPv6 protocol supreme, Dockers makes use of NAT, which has been labelled as completely incompatible and technically backward. Along with the many network layers, speed should be the last thing to expect of Docker admins. The same thought was probably going through Leeming’s mind when he wrote the following:
These problems are caused by the poor architectural design of Docker as a whole, enforcing linear instruction execution even in situations where it is entirely inappropriate (per #2439).
Docker lock-in and security
The promise that no new language, framework or no new packaging system is necessary for Docker stands against the fact that, ultimately, the entire development environment and system architecture must be replaced: “Your application has to be Docker locked-in“. The ability of Docker to read shell script shouldn’t be an exclusive privilege of the technology.
The lack of security of repositories in Docker Hub, on top of concerns about the immaturity of admin and management standards has already been explored on JAXenter. This could be seen as evidence of the claim that the enthusiasm for Docker is nothing but hype, and is merely an addition to what other cloud providers are offering.
The big disappointment
The overall theme in all this criticism seems to be the big disappointment that commentators are feeling, given the promise of Docker’s container technology. Andreas Jung summed up in a nutshell what most critics have been saying:
The theory and ideas behind Docker are great, its architecture and implementation is a mess. Docker is completely unusable in production. It is unreliable, it is unpredictable, it is flaky.
What do you think? Are the Docker haters wrong? Share your experiences in the comments below.