Docker Containers vs. Virtual Machines

What is a Virtual Machine (VM)?

The concept of a virtual machine is simple, really: it’s a virtual server that emulates a hardware server. A virtual machine relies on the system’s physical hardware to emulate the exact same environment on which you install your applications. Depending on your use case, you can use a system virtual machine (that runs an entire OS as a process, allowing you to substitute a real machine for a virtual machine), or process virtual machines that let you execute computer applications alone in the virtual environment.

For more details on VMs, and for some background for evaluating Docker vs VM, see the official site: vmware ›

What is Docker?

Docker is an open source project that offers a software development solution known as containers. To understand Docker, you need to know what containers are. According to Docker, a container is ” a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it.” And since containers are platform-independent, Docker can run across both Windows- and Linux-based platforms. In fact, Docker can also be run within a virtual machine if need be. The main purpose of Docker is that it lets you run microservice applications in a distributed architecture.

Docker Architecture

Docker’s architecture is also client-server based. However, it’s a little more complicated than a virtual machine because of the features involved. It consists of four main parts:

1. Docker Client: This is how you interact with your containers. Call it the user interface for Docker.
2. Docker Objects: These are your main components of Docker: your containers and images. We mentioned already that containers are the placeholders for your software, and can be read and written to. Container images are read-only, and used to create new containers.
3. Docker Daemon: A background process responsible for receiving commands and passing them to the containers via command line.
4. Docker Registry: Commonly known as Docker Hub, this is where your container images are stored and retrieved.

For more details, see the official site: Docker product discovery ›

Common Use Cases

Now that you have an idea of what VM and Docker containers are, it’s important to understand the potential use cases for both. While they are both more or less used to develop applications, here is where the differences really start.

Real-World Use Case for VMs

Starling Bank is a digital-only bank that was built in just one year on VMs provided by AWS. This is possible because of the efficiency virtual machines deliver over traditional hardware servers. Importantly, it cost Starling Bank just a tenth of traditional servers.

Real-World Use Case for Docker

Paypal uses Docker to drive “cost efficiency and enterprise-grade security” for its infrastructure. Paypal runs VMs and containers side-by-side and says that containers reduce the number of VMs it needs to run.

• Application development: Docker is primarily used to package an application’s code and its dependencies. The same container can be shared from Dev to QA and later to IT, thus bringing portability to the development pipeline.
• Running microservices applications: Docker lets you run each microservice that makes up an application in its own container. In this way, it enables a distributed architecture.

Docker Containers vs. VMs

At last, we arrive at the big question: how are the two different? It all comes down to what you want to do with them. Below, we’ll mention a few advantages of Docker as opposed to a virtual machine (specifically Docker vs. VMware), and vice versa.

Pricing comparison

• Docker: Free. Enterprise Edition starts at $750/node/year.
• VMware vSphere: Standard license starts at $995.

For more details and a Docker vs VM comparison

Advantages of Virtual Machines

• The tools associated with a virtual machine are easier to access and simpler to work with. Docker has a more complicated tooling ecosystem, that consists of both Docker-managed and third-party tools.
• As mentioned earlier, once you have a virtual machine up and running, you can start a Docker instance within that VM, and run docker container within the VM (which is the predominant method of running containers at present). This way, containers and virtual machines are not mutually exclusive and can co-exist alongside each other.

Advantages of Docker Containers

• Docker containers are process-isolated and don’t require a hardware hypervisor. This means Docker containers are much smaller and require far fewer resources than a VM.
• Docker is fast. Very fast. While a VM can take an at least a few minutes to boot and be dev-ready, it takes anywhere from a few milliseconds to (at most) a few seconds to start a Docker container from a container image.
• Containers can be shared across multiple team members, bringing much-needed portability across the development pipeline. This reduces ‘works on my machine’ errors that plague DevOps teams.

For more details, see an in-depth discussion: How containers and VM are different ›

The road ahead is quickly changing for VMs at least, as Docker is quickly rising in popularity among major corporations. It’s clear that speed and efficiency are the biggest needs for DevOps teams, and Docker is better at providing these over VMs. While it still hasn’t completely replaced virtual machines in production environments, Docker’s potential is being noticed. That isn’t to say that VMs will soon be gone. Rather, Docker and VMs will co-exist next to each other, giving DevOps teams more choices in how to run their cloud-native applications.