Docker, Kubernetes, and containers are indeed powerful technologies that can bring many benefits to a business. But they are not necessarily the right choice for every workload. In some cases, you’re better off sticking with plain-old virtual machines.
That’s why it’s worth having a discussion of the differences between virtual machines and Docker, with an emphasis on which types of use cases and strategies each technology is best suited to support. And with solutions like Weave Ignite that combine the benefits of containers with the security of VMs, you may no longer have to make that choice.
Docker vs. VMs in a nutshell
First, let’s define the similarities and differences between Docker and virtual machines.
Docker containers and virtual machines are both ways of deploying applications inside environments that are isolated from the underlying hardware. The chief difference is the level of isolation.
In Docker, each container depends on the kernel of the host operating system to run. As a result, when you start a Docker container, you start a new process that is visible from the host system. For example, if you start a MongoDB container with Docker, then run
ps -e | grep mongo in a regular shell on the host (not in Docker), the process will be visible.
In contrast, with a virtual machine, everything running inside the virtual is independent of the host operating system. The virtual machine platform will start a process (or possibly several processes) to host a running virtual machine, and the host system can indirectly allocate some of its hardware resources to the virtual machine. But from the perspective of the host system, there is no way of knowing what is running inside the virtual machine. Plus, the virtual machine has to be set up with its own kernel and other software, since it cannot simply share the environment of the host system.
We could go into more technical detail about the differences between the Docker daemon and a virtual machine hypervisor, or how Docker handles storage compared to how you persist data within a virtual machine; but these differences are not typically as important for someone who is simply deciding whether to use Docker or a virtual machine.
So let’s move on and discuss situations in which you might choose Docker, and those where virtual machines would be a better fit.
When to use Docker
Docker is a good choice for workloads where any of the following is a priority.
Docker containers typically start in a few seconds or less, whereas virtual machines can take minutes. Thus, workloads that need to start very quickly, or that involve spinning apps up and down constantly, may be a good fit for Docker.
Because Docker containers share many of their resources with the host system, they require fewer things to be installed in order to run. Compared to a virtual machine, a container typically takes up less space and consumes less RAM and CPU time. For this reason, you can often fit more applications on a single server using containers than you could using virtual machines. Likewise, due to their lower levels of resource consumption, containers may help to save money on cloud computing costs.
Most of the core technologies required to deploy Docker containers, including container runtimes and orchestrators like Kubernetes, are free and open source. This can lead to cost savings while also increasing flexibility. (However, it’s worth noting that in many cases organizations will use a commercial distribution of Docker or Kubernetes in order to simplify deployment and obtain professional support services.)
In Docker, each container is based on a container image, which contains the data and instructions that the container requires to run a given application. Container images are easy to share and reuse using container registries, which are basically repositories that host container images. You can set up an internal registry to share and reuse containers within your company. You can also download thousands of prebuilt images from public registries for free and use them as the basis for building your own containerized applications.
Of course, virtual machines can be packaged into images, too, and those images can be reshared. However, virtual machine images are typically much larger in size, and because they usually include operating systems, redistributing them can become legally complicated. (In most cases you can’t legally download and run a virtual machine image with Windows preinstalled without having a Windows license, for example.)
When to stick with virtual machines
Now that we’ve sung Docker’s praises, let’s look at some reasons why you might forgo Docker and stick with your virtual machines.
Ease of deployment and management
Arguably, virtual machines are easier to deploy and manage than Docker containers, simply because virtual machines involve fewer moving pieces. You simply install your hypervisor (like VMware or KVM) and start your virtual machines. With Docker, you need to install Docker itself, then pull container images, then start each image separately. For production workloads involving more than a handful of containers, you also need an orchestrator and load balancer to manage all of the containers.
A full discussion of the security merits of virtual machines as compared to Docker is beyond the scope of this article. But suffice it to say that, essentially, virtual machines are more isolated from each other and from the host system than are Docker containers. That is because virtual machines, as we’ve noted, don’t directly share any kernels or other resources with the host system.
For this reason, virtual machines are arguably more secure overall than containers. Although Docker provides various tools to help isolate containers and prevent a breach within one container from escalating into others, at the end of the day, containers aren’t isolated from a security perspective in the same way that virtual machines are.
Today, most virtual machine platforms work on every major operating system, and you can run any type of operating system that you want inside your virtual machines. Thus, you could deploy a Windows virtual machine on Linux, or vice versa. This portability is handy if you have an infrastructure where you need to be able to deploy one type of operating system on another.
Docker is not as portable. Although in some ways Docker reduces dependence on your operating system (for example, you could run the same Docker container on Ubuntu or CentOS, even though each of these Linux distributions uses a different type of package management system), Docker doesn’t provide portability across operating systems. Docker containers for Linux only work on Linux hosts, and the same holds true for Windows. (Plus, Docker only works on certain versions of Windows, which is another portability limitation.)
Many modern virtual machine platforms make it easy to “snapshot” virtual machines at a given point in time, and to “roll back” a machine when desired. This can be useful when dealing with data corruption or security breaches, among other issues.
Docker doesn’t offer the same type of functionality. You can roll back container images, but because containers store their data outside of the image in most cases, rolling back an image won’t help you recover data that was lost by a running application. It also won’t necessarily help you stop a security breach, unless the breach was caused by an issue within a particular version of your container image.
At this point, the last big disruption in the world of virtual machines was the entry of KVM as a production-quality solution about a decade ago. Otherwise, virtual machine software and strategies that worked circa 2001 are still viable today. Virtual machines in this sense are a very predictable, stable technology. Businesses don’t have much cause to worry that the virtual machine software or strategy they adopt today will no longer be relevant in a few years.
The same is not true of Docker. Since Docker itself debuted in 2013, the Docker ecosystem has evolved and changed enormously. Orchestrators like Mesos and Docker Swarm have been supplanted by Kubernetes. On-premises container deployments have been replaced in many cases by cloud services like AWS EKS and Azure managed Kubernetes service, AKS, which have themselves changed significantly in terms of the technologies they offer.
Weave Ignite - VMs that look and act like containers
And now you have the option of combining the usability of containers with the security of VMs with the microVM solution Weave Ignite. Ignite is built on Firecracker, a technology developed and open sourced by AWS and used to spin up Lambda serverless functions in Fargate. Weave Ignite is an open source solution for spinning up microVMs in minutes, that look and act like containers, but offer the isolation and security of VMs. The best part about Weave Ignite microVMs is they are completely declarative and can be managed from a git repository using GitOps.
(from: Ignite - container workload in real virtual machines) - See that post for a nice walkthrough on how to use Ignite.
Docker containers are a wonderful technology that makes it possible to deploy applications faster and with lower levels of resource consumption than virtual machines. But virtual machines continue to have their own killer features, like a higher degree of portability and full support for image rollbacks. If it’s VMs you want to run with the portability and ease of managing containers, take a look at Weave Ignite.