Containers vs Virtual Machines (What is Docker ?)

Today, we have a hot topic to dig into: Containers vs. Virtual Machines. Are you sure you understand the difference between the two? While going through a challenge building Docker with Go, I realised I hadn’t quite grasped what a container is.

Let me ask you this question: Do you know under which conditions running a Docker container is at least as expensive (computationally ) as running a virtual machine?

If you don’t know the answer to that question, stick around. We’ll be working out the answer to that and more, such as: What is a VM? What is a container? What are the differences between a container and a VM? Why is a container more lightweight(generally speaking)? What are the drawbacks of using a container when compared to a VM?

The first step is to understand what a VM (or Virtual Machine) is.

What is a virtual Machine?

The film “The Matrix” asks: “Are we living in a simulation?”. For Virtual Machines, the answer to that is “yes”. A Virtual Machine (or VM for short) is software pretending to be a computer.

What is the structure of our computers? They have hardware: a CPU, Memory, a hard drive and so on. On top of that, we have an operating system, and on top of the operating system, we have the software.

The software is where the VM lives. A Virtual Machine is (basically) simulated hardware. It has a virtual processor, hard drive, memory, and so on. Software pretending to be hardware. In turn, the simulated hard drive contains a whole new operating system.

This is what allows us to (for example) run Linux on Mac or Windows.

This is also the tech allowing us to run simulated mobile phones and tablets (which tend to have processors with an ARM instruction set) on our computers using Xcode or Android Studio.

For those of you wondering: Yes, you can run VMs inside VMs inside VMs… although there is a limit to that. Why?

Simulating a whole system can be costly: not only does the computer have to run its operating system, but it also has to run simulated hardware and the guest operating system (and then any software running on that).

And this is where containers come in.

Conceptually, containers share a lot with virtual machines. In a sense, they are the next step in the evolutionary path that virtual machines started.

But that also causes a lot of confusion as to what exactly the difference between the two is.

So, why are containers the next step after virtual machines?

Let’s look at what containers are, exactly, and how they improve on virtual machines.

What are containers?

In a nutshell, virtual machines add, but containers.. subtract. Let me explain.

Let’s get back to our computer, with its three layers. If we dive into the operating system layer, it too has layers with different roles. The deepest one, the kernel, interfaces directly with the hardware.

A container is a walled-off “slice” of the environment, which sits on top of the kernel. It has its own personal but limited share of the memory and the hard drive and the CPU processes that it can use.

It can’t see the rest of the environment. It can’t access any part of the filesystem, memory, or processes that don’t belong to it.

It simply speaks to the same kernel as the rest of the computer software to interact with the hardware, so it shares the same hardware and part of the operating system.

All it can do to communicate is use its share of the network hardware to send and receive network messages, including to other containers on the same computer.

Because the container shares the hardware and OS instead of simulating them, a container is generally less expensive to run than a virtual machine.

However, there is a situation when a container is more expensive than a virtual machine. Can you see when that can occur?

That question brings us to container technology’s strengths and weaknesses, and the question: why use containers instead of virtual machines?

Why use containers vs virtual machines?

I’ve mentioned that containers are lightweight. That’s their first strength.

Container’s second strength is that they are disposable. At first glance, that might seem like a weakness. But a disposable environment is also one that has a controlled, repeatable behaviour. That has two very important advantages.

First, it means a container on my machine works exactly the same as one on yours. It avoids the “well it runs on my machine” syndrome I’ve seen so many devs resort to (and to be honest, I’ve used that excuse too).

Second, a lightweight, repeatable environment is easy to scale up and down depending on the need. Disposability provides scalability.

Now, containers also come with several costs and downsides.

First, there is a setup cost. It’s harder to configure an environment within a Docker container, precisely because the configuration needs to be repeatable.

Second, containers are also **less secure **than virtual machines since they are closer to the final hardware, so a weakness in the isolation could spell trouble.

There is another weakness, and it is the answer to the question: “When is a container more expensive than a virtual machine?”

You see, containers are repeatable, but what happens if I have a Mac and you’re running Linux? Surely a walled-off section of a Mac machine and a Linux machine won’t work the same way?

Well… No, they won’t.

So, how do container services run on non-Linux machines? … They run a Virtual Machine that runs Linux.

So when is running a Docker container more computationally expensive than running a VM? When you need a VM to run a docker container.

That being said, if running one container on one VM is more expensive than just running a VM, running a bucketload of containers is a lot less expensive than spinning up the same number of virtual machines.

Or, to phrase things differently, the cost is worth it.

If you’re interested in getting more hands-on knowledge, I suggest you follow the Docker building challenge I went through, I’ve provided a link in the description.

And in any case, I’ll see you in the next video!