Docker Containers vs VMs
Tags: docker, containerization, containers, vms
Published: 2019-07-21 15:26:11

---
title: Docker Containers vs VMs
published: true
description:  Virtual Machines (VMs) and Docker containers are two technologies used to improve resource utilization. This post will help you understand the background of both as well as how they differ. 
tags: docker, containerization, containers, VMs
cover_image: https://thepracticaldev.s3.amazonaws.com/i/ashm2ss6vc6ool7he92p.png
---

**Virtual Machines (VMs)** and **Docker containers** are two technologies that can help with resource utilization, enabling you to run multiple apps in isolated environments on the same infrastructure.

Given a terminal on a VM or a container, either will behave much as though it was in fact a dedicated machine. This can make it hard to differentiate between VMs and containers, especially if you are just getting started with Docker. To help with that, this blog post will show you how both function under the hood, while pointing out their similarities and differences. No previous knowledge of VMs or containers is necessary for this post.

#### Virtual Machines and Containers

VMs have been around for a long time, allowing physical machines to run multiple operating systems and multiple isolated apps. VMs are similar to "regular" physical computers: they run an operating system, have a lot of libraries installed, and run applications. The difference is that a virtual machine does not have its own dedicated hardware. Instead, VMs use the physical machine's underlying infrastructure through software that imitates dedicated hardware. The software that virtualizes hardware for VMs is called a hypervisor.

![Multiple VMs that run on top of a hypervisor which regulates access to underlying infrastructure.](https://thepracticaldev.s3.amazonaws.com/i/b7ln74cl0po6wrd75ja4.png)
<figcaption>Source: https://docs.docker.com/get-started/#containers-and-virtual-machines</figcaption>

The fact that each VM has its own operating system makes VMs require quite a bit of storage and other resources. To reduce the needed resources per running application, people came up with containers.

While containerization had been around for a while on various operating systems, the community rallied behind Docker which was first released in 2013. During that time, the tech world (and the DevOps world in particular) was looking for solutions that would make deploying and scaling microservices more efficient. Docker managed to address that need by making Linux's LXC containerization easier to use and more accessible. They took the heavy lifting and planning that usually went into configuring a container and turned it into writing a Docker file which then did that work for you. This ease of use is what made Docker so popular; the fact that Docker was open source from the start certainly also helped.

Containers allow developers to minimize the resources they need by only packaging an application and its exact dependencies. Instead of running on a hypervisor the containers run on top of a container runtime environment which is installed on an operating system. While VMs use virtualized hardware, containers use underlying resources of the host operating system.

![Multiple containers that run on top of Docker which is installed on the host operating system which regulates access to underlying infrastructure.](https://thepracticaldev.s3.amazonaws.com/i/hz62tbfvkjntiqq4778h.png)
<figcaption>Source: https://docs.docker.com/get-started/#containers-and-virtual-machines</figcaption>

Comparing VMs and containers to houses and apartments can help make these differences more apparent: A house has its own water pipes, its own internet cable, and its own garbage disposal system. Apartments on the other hand have these resources managed by their apartment complex and can access the resources of the entire building without having to each have their own separate version. House rules ensure that apartment residents do not irritate each other and get a fair share of all resources.

Virtual Machines are like houses in this comparison. They each have their own operating system with its own dedicated resources (e.g. kernel, filesystem, process tree, network stack). The VM accesses CPU, storage, RAM etc. through a hypervisor which virtualizes the hardware.

Containers are much more like apartments. They only have exactly what they need to run their application. They share the underlying operating system's resources (e.g. kernel, filesystem, process tree, network stack) which are isolated by the container runtime environment which enforces rules around the resources particular containers have access to. Overall, this model makes containers a much more lightweight solution.

These differences in how containers and VMs function under the hood make containers a lot faster to provision and means they are often (and generally should be) used as immutable, non-persistent constructs. Containers live and die and are largely not something you ought to care about (unless they all die at the same time!). VMs, on the other hand, often have a longer life span, you spend more time configuring them and you probably care if something happens to them.

On a high level, the differences between containers and VMs can be summarized by saying that VMs are considered to be a virtualization technology and containers an application delivery technology.

#### Learn more
This was our concise overview of VMs and containers. If you are interested to learn more, check out: 


* [Docker Jargon: FROM Dockerfile to Container](https://dev.to/npentrel/docker-jargon-from-dockerfile-to-container-942)
* [Docker tutorial](https://www.youtube.com/watch?v=wjvyN_r-zkk)
* [Docker cheatsheet](https://github.com/npentrel/SmoothDevOps/raw/master/cheatsheets/01%20Docker%20Cheatsheet.pdf)
* [Docker's get started guide](https://docs.docker.com/get-started/) 
* [Nigel Poulton's Docker Deep Dive](https://www.amazon.com/Docker-Deep-Dive-Nigel-Poulton-ebook/dp/B01LXWQUFF)
* [orhandogan.net/docker/](http://orhandogan.net/docker/)