While containers are a wonderful way to package applications, but while the rest of the internet talks of all the things you can use them for let’s mention a few cases in which you shouldn’t use docker.
Let’s start with the clickbaity top image. It’s a cat, which is an amazing allegory for how Docker containers work! On one hand, they have a strong tendency to enter random boxes and then proceed to do nothing inside, or whatever else cats do. The box will mostly restrict the cat’s movements, and if you want to poke her from a random angle you have to make a hole in the container at that point. And just as containers to some degree encapsulate your app from the rest of the world.
The clickbaity title of this article would be “10 alternatives to docker” or “Why you should stop using Docker right now!”. But let’s get real, you will probably keep using docker. As of 2020, it’s still a defacto way to package and run containerized workloads. Most people just take it for granted, but like every design, Docker has tradeoffs that may end up hampering your particular use case. Additionally, reading this will help you roll eyes when you see posts like “Kubernetes is Removing <<>> Support“.
Workloads for which you should avoid docker
Anyhow, let’s look at some workloads where containers will actually hamper your ability to maintain operational targets.
High performance, low latency applications
Applications that require very high-performance (simulations, number crunching, Machine Learning, Neural Networks), or very low network latency will suffer performance degradation. Also, you might run into problems if they require direct access to specialized hardware. Think of a supercomputer, where scientists upload some simulation code to a platform & point to a dataset. It’s quite common, especially in scientific computing for the whole platform to provide for a standardized way of deploying new learning workloads. This can make it harder or even useless to try to deploy workloads through docker.
Databases
Large databases, the kind that takes up multiple high-end servers will significantly lose the ability to operate at high loads if containerized. It’s perfectly adequate to run your little DBs of few dozen gigabytes in containers with host folders for persistent storage. Just don’t expect to run the production DB of a popular website using such an environment.
Desktop GUI based applications
While nowadays technically possible, it’s unlikely that you will have a good development or production experience if you try to run apps that are meant to work only through a GUI using docker. Compared to the maturity of network and Linux standard stram based communication with the containers, GUI support is pretty minimal. GUI wrappers for CLI tools (as is common with most Linux desktop apps) should work fine.
Applications not built to run on Linux
Nowadays you can run docker containers on Windows, and even run Windows Docker containers on Windows. It works quite well on the Server and Windows 10 Pro edition. There are some quirks and bugs on the Home edition. But there is no option to run Windows containers on a Linux host. And there may be some known limitations for such a setup.
Legacy code meant to run on dinosaur hardware
Are you one of the chosen few that maintain the ancient mainframes of international banking. Well, containers are unlikely to help you feat the evil that lurks in that codebase. You are one of the select few in IT who might benefit from a big rewrite. Although keeping everything as is and operational might be enough work to keep you employed for a lifetime. You might even make enough to afford that cryogenic sleep associated with COBOL programmers.
In all fairness, porting a legacy complex system to docker will be quite challenging. Especially if you’re not able to account for all the little config files and are unable to reliably test the dockerized replica of production. In case you go into this endeavor do remember to attempt to split up the monolith into a few functional microservices, or to at least separate the 3rd party “companion” software into their own containers. In case you decide to go to the opposite of monolith, aka the “1 feature 1 microservice, keep in mind that that approach also comes with tradeoffs.
Docker alternatives for those whose curiosity can’t be containe(r)d
Docker builds on top of OCI compliant containers and runtimes. Any OCI compliant project can run containers build with OCI image spec. Most of the alternatives strive to provide a solution to a particular problem or to provide a more secure environment than baseline docker. In case you want to understand these concerns more in detail check out this post, or this article series.
While at the time of writing none of the technologies below are really as mature as docker, they might be a good starting point in case you want to dig deeper into docker alternatives for academic or professional reasons:
Few alternatives to docker containers:
- Docker-engine – you shouldn’t look for alternatives till you evaluate what you want to alternate 馃榾
- LXC – predecessor and initially the base of initial docker. Linux containers still present a way to efficiently start kernel virtual machines.
- CRI-O – OCI compliant implementation focusing on kubernetes. Soon to be the default container runtime in kubernetes.
- containerd – the opensourced section of docker that handles management of containers. Very usable as a low-level runtime but without high-level features that most people associate with container-based workflows.
- gVisor – Google-backed they strive to reduce the number of syscalls a container can make to host kernel by putting an intermediary kernel to handle most requests.
- Firecracker – Amazon backed and used for Amazon’s Serverless offering.
- Kata – Openstack backed, starts each container within a virtual machine
- Nabla – Build on top of Unikrnel bundles that have only 7 system calls that reach the host kernel.
- Unikernel – basically a stripped-down OS that only has the components you need to run your app. Any unikernel platform by definition can fulfill a similar role as VM or container.
- Singularity – a container platform focusing on HPC (High-Performance Computing)
- runc – don’t like docker? just use the base component that provides virtualization without bothering with the rest of the platform!
- rkt – docker alternative developed by coreOS. unfortunately, declared dead in 2020, but it has some nice architectural ideas as well as a nice comparison to other platforms.
Further reading
- A Basic introduction to containers
- OCI Runtime
- OS level Virtualization
- A nice comparison between different providers
- RKT’s comparison to other projects
- A good introduction into how runtimes work and how to implement containers by hand
- docker components explained
- A look at more isolation/security-oriented projects
- Workload characteristics of containerization
This is part two of a series of articles on Docker and Containers. Check out part 1 on “Dive into how Docker containers work“. In case you’d like to know or discuss more feel free to poke me on Twitter @buzzwrd_me,