Dan Jones’ recent article in Network World “Containers vs. VMs: It comes down to state management, networking, and sprawl” responds to some specific concerns regarding possible pitfalls when implementing Docker instead of more traditional VM architectures (only in IT can something just over decade old be considered “traditional” ).
Dan discusses Docker’s evolution towards parity in some of the key business values of using VMs. Specifically, managing resources and guarding against sprawl or over-proliferation, networking flexibility and features, and the ability to suspend and save machine states. These problems manifest in almost any development and deployment environment and may be somewhat more difficult to address in Docker, but in all three of these arguments, Docker also has some advantages over traditional VMs.
When people talk sprawl and over-proliferation of virtual machines and services, the main concern lies in managing and administrating the resources. When it comes to terminating machines or containers, Docker has a clear advantage, which is image determinism. Since Docker containers maintain a clear revision history and state, identifying containers built off the same image is quick and simple.
Replacing containers with identical containers built off the same image is also painless. With VMs, manual management of snapshots, mappings of instances to images, and VM versioning is all administrative overhead. Docker’s ability to provide deterministic history of containers and images makes managing potential sprawl easier and safer.
If we talk about networking, virtual machines are certainly more flexible and can support a wider set of configurations and topologies. Docker, on the other hand, can use a simplified bridge network within a host, or their overlay network between hosts. The design of the Docker overlay network allows you to form several Docker machines into a single entity called a swarm. This allows Docker to be broken into separate management entities. The container acts as the smallest unit, the Docker engine acts as its own independent entity for management purposes, and the Docker Swarm is an even larger aggregated entity. This provides Docker entities with a certain autonomy from a management perspective. Swarm can be managed as an aggregate, without requiring management of a Docker engine or Docker container. Conversely, a container can be managed without involving the Swarm management. The value of technology can be judged by simplicity as easily as it can be judged by complexity.
The value of suspending a machine state is definitely valuable, especially in the development world, and VMs have that value, but using a different workflow, the ability to have quick and cheap disposable environments and services can be seen as a way around the problems that suspend helps solve. Docker’s ability to discard and spin up lightweight environments easily, automatically, and reliably, means the idea of the single unit uptime becomes irrelevant, and service uptime becomes the new value.
The server process running for years has been an impressive benchmark, but with stateless models, it’s also unnecessary. Being able to throw away containers with exhausted buffers, counters, leaked file handles and other misbehaving elements, and spin up new ones, as well as being able to step backwards through the generations of images on a container means it’s easier to throw it away and get a new one than repair the old. Long-lived machines collect cruft, run counters past their bounds, and leak memory.
The cost of rebuilding and replacing a VM in a hypervisor is cheaper than a reboot, but still it’s time-consuming, and generally requires manual management. Docker features make this process so inexpensive, you can dispose of old containers and replace them with new ones so easily, there is no reason not to do it before anything even manifests. Combined with the strict versioning found in Docker images, there is not even the worry of bringing in out of date or too soon images. using a registry and well-crafted tagging model greatly reduces the chances for manual management of individual instances.
As Dan said in his article, sometimes VMs are the right tool (like a hammer) and sometimes Docker is the right tool (like a screwdriver), but to extend his metaphor, just because the wall is built with nails hammered into the plywood, doesn’t make it better than the wall built with wood screws. Your design should dictate the correct tools. Your tools shouldn’t dictate your design.
