Containers and virtual machines, what are differences and when should you use each? This has become a very common question as containers rise in popularity. The goal of this article is to highlight the major differences between the two technologies, allowing to understand when one should be used over the other.
Virtual Machines
A virtual machine, as its name depicts, is a virtual computer. It operates exactly the same as a physical machine. We add all of the same components, such as CPU, RAM, storage controllers, storage, network interfaces, and so on.
A virtual machine also has a full operating system installed. We can do virtually anything with a VM that can be done with a physical server.
Virtual machines were introduced as a solution to use existing hardware more efficiently. Rather than having to procure and provision an entire physical server to run one service, we could save costs by purchasing a slightly larger server and host many services.
While other technologies, such as containers, have been popularized via tools such as Docker, virtual machines still have their place. Not all applications or services should run in a container. Large complex, monolithic applications should not. You wouldn’t want to run WebSphere in a container, as it would require administrative tasks that become difficult or impossible in a single container. However, WebSphere fits perfectly in a virtual machine.
Containers
A container is an isolation of processes and files. It’s considerably more lightweight compared with virtual machines.
There is no operating system or hardware virtualization. That alone can significantly decrease storage. It has just the binaries required to run some processes, and present an endpoint to interact with it.
With the ability to isolate files and processes, we can run many different versions of an application or service on the same host. Something that can be difficult or even impossible on a virtual machine or physical server.
Containers are also highly portable. It’s trivial to move your container from one host to another or to one hundred. That in itself is the most valuable feature.
Containers on VMs
It was a common belief during Docker’s rise in popularity that containers would replace virtual machines. It was a strange argument since the two technologies don’t actually compete with each other. Rather, when used together, they provide additional efficiencies to physical hardware.
If a physical Docker has experienced a catastrophic hardware failure, it will go offline — end of story. That could be detrimental to the availability of your services. Now, nearly every virtual environment is architected to fail virtual machine over to a new host when the original host goes offline unexpectedly.
Therefore, by virtualizing our container hosts we are providing better service uptime. We can then further optimize our system resources by provisioning several containers on the host, that only require enough storage and system resources to power the services they offer.
Introducing orchestration services, such as Kubernettes, to manage our containers and we further improve our application’s availability. We can easily scale and provide better fault tolerance, meaning our customers rarely become impacted by a hardware failure.
