What’s the difference between containers and virtual machines?


I was at a conference recently when I realized the person I was talking with thought that containers were just smaller versions of virtual machines (VM). Ah, no. No, they’re not.

Yes, they can function in the same ways from a practical viewpoint. For example, they’re both commonly used to run server applications. How they do that is where things start to be different between them. This, in turn, leads to them being good for different kinds of IT jobs. 

Virtualization enables a single server to run multiple operating systems and applications simultaneously. For example, I often run both Ubuntu and CentOS Linux on the same server.

Virtualization is done using a program called a hypervisor. Some of the most commonly used hypervisors are Linux KVM, Microsoft Hyper-V, and VMWare ESXi These provide the VM, which contains the guest operating system, with a virtualized abstraction of the underlying computer hardware. The operating system then runs on the VM with the hypervisor taking care of transferring its requests to the physical CPU, network and storage.

From a user’s viewpoint, the virtualized operating system looks and feels just as if it were running natively on the hardware. So, when you use a VM, you can run not just the operating system, but the full application stack.

Containers, however, share an underlying operating system. Typically, they run on top of Linux and share the operating system’s resources with its resident programs. Within a container you find not an operating system, but just the components, such as the core program and libraries your application needs to run.  

This makes containers much more lightweight than VMs. A container might be as small as a dozen megabytes, while a typical VM is as large as a gigabyte. This also makes them more efficient than hypervisors in using system resources. The net result? You can run more applications on a given machine with containers than with VMs.

Containers also, as you might guess, can boot up more more quickly than a VM. This makes them ideal for running applications that need to spring up and then spin down again as workflows demand.

In addition, because a container holds just the code you need to run a given program, they’re ideal for packaging programs. Containers enable your developers to easily pack, ship, and run an application as a lightweight, portable, self-sufficient container, which can run virtually anywhere. This makes them especially handy for Continuous Integration/Continuous Deployment (CI/CD)

So, if containers are so wonderful why aren’t we all using them in place of VMs? There are several reasons. First, containers are theoretically more insecure than VMs. In practice, containers can also hold bad, out-of-date software that comes with security issues. Containers can also be harder to manage–albeit Kubernetes is taking care of the management issue.

Virtualization is also more flexible in some ways. For example, with VMs you can run multiple operating systems and applications. You can also run–and most people do–containers in VMs for the best combination of flexibility and getting the most efficiency from your server hardware.

So, while at the end of the day both containers and VMs let you run applications, they take different paths to the same goal. And, they come with their own unique virtues and vices.



  1. Jonathan Sproule says:

    Thanks for the blog Steven. I was doing some work recently on containers and will be doing so again.



  1. […] What’s the difference between containers and virtual machines? More> […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: