Containers vs Virtual Machines (VMs)

As microservices gain in popularity, containers have become a hot topic for developers. But how do they differ from virtual machines? Will containers replace virtual machines? And when should you choose containers over virtual machines?

Micro Machines for Microservices

When it comes to defining virtual machines, the name says it all – machines (servers or desktops) that have been virtualized. The operating system, applications, and services are all bundled into a single image that is accessed via a hypervisor, built on virtualized hardware.

Containers, such as Docker and Kubernetes, are slightly different. Containers typically contain a single app or microservice, alongside the various runtime libraries they need to run. Importantly, they do not contain an operating system and they do not need a hypervisor to run – they run on a shared engine kernel, thus effectively operating on bare metal.

When to Use Virtual Machines

Ideal for “lift-and-shift” migrations, virtual machines allow you to quickly move a fully functioning system between locations. Virtualizing local servers and migrating them to the cloud is a common way to begin the journey towards cloud-based operations, for instance.

Virtual machines are also an effective approach to dealing with legacy systems that do not offer cloud-native operations. Bundling legacy applications and all their OS requirements into virtual disk images offer an effective way to finally offload them – and to delay a costly redevelopment project.

These virtual machines images are also a good choice for when your applications and services need to run across multiple operating systems in the data center. They are not restricted to a single OS kernel in the way that containers are.

Drawbacks of Virtual Machines

Because virtual machines are wholly contained ‘units’, they do not automatically scale well. You can automate and accelerate the process of spinning-up new machines as demand increases, but the resource cost increases exponentially. They consume more billable hardware resources than containers too, adding to the time it takes to spin-up new instances. You must pay for all the resources – CPU, disk, RAM, OS, and application licenses, etc. – allocated to the image, even if they are not used.

A full virtual machine has all the same management overheads of a physical machine, too. The operating system and applications must be regularly updated and patched, for instance, which adds to the cost and management overhead of operation. You must also devote resources to managing the security permissions required to execute your applications on the virtual machine.

Virtual machines have been a convenient first step toward cloud-native operations and they certainly increase operational flexibility. However, the cost of operation can be far higher than expected over the longer term.

When to use Containers

Containers are, by their very nature, lightweight. Designed to fulfill a specific task, containers are assembled and linked to build a fully functional application or service without the overhead of an operating system or full-size helper applications.

This approach dramatically improves scalability. As demand increases, rather than spinning up a complete virtual machines, you can simply spin up another cluster node to make more containers available. You don’t have to spin-up all containers either, but (with effective resource monitoring) start with only those that are experiencing particularly high levels of demand. As demand falls back to normal levels, the additional cluster nodes can be spun down, reducing the overall resource footprint once more.

Because of the smaller footprint, containers are better at limiting cloud resource demands and costs. Containing only runtime libraries, you can also reduce licensing costs associated with a full virtual machines.

Applications built on Docker and Kubernetes containers also enjoy enhanced portability. Operating without a guest OS, they can quickly be ported across almost any platform capable of running the containerization engine. This “write once, run anywhere” design helps to minimize compatibility issues in future.

When code needs to be updated, developers typically deploy an updated container, rather than patching the existing code. This allows for very fast updates and rollbacks because only the affected container needs to be touched. Virtual machines offer the same disposability (replacing the existing image with an updated version), but their larger footprint means the process takes longer than it does with containers.

However, containers do create new challenges for developers. As they use a shared OS kernel, compromising one container operating with elevated permissions provides a way for malicious actors to compromise the entire host system. The technology does not offer a native isolation mechanism in the same way that virtual machines running on hypervisors do.

Not Necessarily an Either/Or Choice

As cloud technologies have evolved, more people have begun to ask, “Moving forward, should we choose virtual machines or containers for our application infrastructure?” But this is not the correct question as each technology is designed for a different use. Instead the question should be, “Which technology better suits our workload?”

Virtual machines and containers each have different roles; they cannot simply be swapped on a like-for-like basis. They both have a place in the modern IT environment.

The VM or Container decision must be taken on a case-by-case basis, considering the specific demands of each workload. Although less ‘sexy’, virtual machines may still be the appropriate choice in many instances. It may be that security concerns about the shared OS kernel means that containers are unsuitable for particularly sensitive applications. Or that the increased uptake of microservices demands the use of containers.

Analysis of workloads within your data center (or cloud environment) will help to expose performance bottlenecks that need to be addressed and identify opportunities for improvement. It will also provide evidence to help you identify candidates for redevelopment into containers. These insights will help to avoid best-guess strategic decisions, allowing you to make full advantage of the correct virtualization technology for each project.

Note: VMs and containers should not necessarily be seen as rivals. Rather, you can use both to balance the workload between the two.