Hello Muser!

In our last newsletter, we talked about Docker and building a container from scratch. While it's tempting to think of containers as miniature VMs, there are some key differences that need to be pointed out so we can understand where we should and shouldn't use containers. So, before we talk about how Docker containers and Ansible for VMs are SIMILAR to each other, let's go through what sets them apart.

Simulated Technologies

You've seen "The Matrix," right? The classic sci-fi movie where humans are stuck in a simulation without even realizing it? Let's use that as the backdrop to explain VMs and Containers. I read many articles before this analogy came to mind and it's still how I see the differences to this day.

VMs: The Regular Folks in The Matrix

Think of VMs as the regular people in the movie. They're in the Matrix, believing it's the real world. They don't know they're in a simulation. Similarly, VMs think they're running on their own dedicated hardware. This gives them a sort of "bubble" that makes them secure and isolated. But, this bubble comes at a cost. They can use up a lot of resources because they think they've got a whole machine to themselves.

Containers: The Quick Agents

Now, let's talk about the Matrix Agents. Those guys who can jump in and out, using the greater resources of the Matrix, and bending the rules (because they know more about the system). That's like Containers. They're super lightweight and don't need to pretend they're on a dedicated machine. They share things with the host and other containers, making them fast and efficient. And since they're so intertwined with the host, they get to play with a larger ruleset.

If you’ve used Docker before, what helped you to understand the difference when you first started?

VMs vs. Containers: Why The Differences Matter 

For me, when it comes to understanding the difference between VMs and Containers, I like to consider 3 main points:

• How many do you need to run on your machine (capacity/density)?

• How quickly do you need to get them operational (deployment speed)?

• And how much separation do they need from each other (isolation)?

1. Capacity (Density)

Imagine a VM as a complete computer inside your actual computer. Because it believes it's its own device, it demands its fair share of resources such as memory and storage. This means you can only have so many VMs running before your computer starts feeling the pressure. Diving deeper, each VM operates its own full operating system, which includes virtualized hardware. This naturally takes up more system resources, putting a cap on how many VMs a single host machine can efficiently run.

On the other hand, containers feel more like running applications on your computer. They're not as greedy because they're skilled at sharing. This lets you run many more of them compared to VMs. To understand why, containers use the core functions of the host's operating system without simulating full hardware. This efficient nature allows you to run a higher number of containers on a single host.

2. Deployment Speed

Starting a VM feels like booting up a brand-new computer. It can be a slow process, especially if that 'virtual computer' has a lot of tasks to complete before it's ready. The technical side of this is that booting a VM involves firing up an entire operating system, which can be time-consuming based on its resource requirements and startup processes.

In contrast, containers are lightning-fast. Think of it as quickly launching a program on your computer, and it's ready in a flash. The reason behind this is that containers tap into the host's operating system and don't need to kickstart a whole new system. This results in an almost immediate launch, similar to getting a new process running.

3. Isolation

Each VM is its own bubble. If one faces issues, it doesn’t usually affect its neighbors. Think of it as having separate computers; if one malfunctions, the rest keep humming along. In more technical terms, VMs offer strong isolation as they run independent operating systems, providing a protective barrier against interferences.

Containers, while isolated, share some resources. Like apps on the same computer, they're distinct, but because they share some resources, a misbehaving container might impact its neighbors. While containers do offer a level of isolation by separating the application's environment from others, they all operate under the same host OS. This shared environment can sometimes lead to inter-container disturbances. From a security perspective, it's much easier to pivot from a container and get access to the host operating system than it is in a VM.

When choosing between VMs and Containers, weigh your needs. If you seek distinct, independent environments, VMs shine. But for swift, resource-efficient tasks, containers take the crown. Often, a mix of both provides the optimal solution!

Ansible vs Docker

So now, full circle, we come back to configuration management. Now that we understand the differences between containers and VMs, we can talk about the choice between Ansible vs Docker.

• Choose Ansible if you're managing traditional infrastructure that is NOT containers. This includes VMs, networking gear, etc.

• Choose Docker if you have an application that can benefit from the speed that containers can start with, doesn't need hard isolation, and you truly want to pack in the number of running instances on the resources you have

These are general guidelines but there are always exceptions which is why I wanted to go through the technological differences. Understanding those will give you a better foundation to reason from first principles when making a decision about which solution to use.

Next time, we'll go through more about how to use Docker to manage containers and what infrastructure is usually associated with containers! We'll cover software artifacts, container registries, and how these relate to Docker images!

Confusion about how containers & VMs are different? Questions about how to pick Ansible or Docker?

Enjoyed this post? Don't miss our next one where we'll explore different tools available for configuration management. Subscribe now and share with your colleagues who might find this useful!

Keep learning and keep growing,

Darrell