Containers vs. VMs: 3 Virtualization Failings Containers Fix

Rania Mohamed

By Rania Mohamed, Solutions Architect, SUSE Global Services

Virtual machines have been instrumental in advances in cloud development and modern application and infrastructure design. But let’s face it: VMs have problems that are becoming more evident as technology stacks mature.

The three top problem areas:

• Failover. VMs aren’t able to deliver high service-level agreements for failover. For every failing VM, a complete virtualized machine must be built — a technician must install the operating system, configure the network, install the application and configure the VM. While we do have some solutions today that can provide automation, this gap isn’t fully closed, especially if you must deliver a 99.99% SLA for an application.
• Complexity. A VM is still a machine — it has a rich operating system, so it can be complex to install drivers, configure security and install and deploy applications. Complexity always matters to MSPs. It affects cost, maintenance, upgrades and the services you can deliver.
• Cost of horizontal scaling and limitations of vertical scaling. VMs are pretty costly to scale horizontally and have limited ability to scale vertically. A question you might ask at this point: “Why do we need scaling? Let’s just plan out full resources ahead of time.” While it’s true that you could work with a customer to forecast all possible resource demands, it will cost you and them a lot of coin – a lot of coin – with no benefit and no revenue. For example, think about LinkedIn, or any other social platform. To prepare for the worst-case (or best, depending on your point of view) scenario so that the service is never down and always serving clients, it would need to provision resources for every current and potential subscriber to get access at the same exact time. That’s a lot of money, especially if you have variable load in the equation.

Shouldn’t a VM solve those problems? The short answer to that question is, unfortunately, no. VMs are built on the concept of handling monolithic, not modular, applications. With a VM, if there’s a need to scale horizontally, you’d need to add a completely new VM to the environment, with a full setup of the OS and application, even if the load demand is one single service or a couple of modules. As outlined previously, scaling horizontally using VMs isn’t cost efficient. Remember, there’s always a vertical scaling limit, which will vary based on the underlying infrastructure and the operating system and runtime.

The other problem for MSPs vis-à-vis VMs is time. Time matters to partners and applying a patch or upgrade, or performing a restart or rebuild, of a VM takes a technician away from other, higher-value tasks.

A Container Fix to these Problems?

I argue that yes, containers do fix these other problems. A container is essentially a lightweight, standalone application that holds all its dependencies and can run by itself. Let’s check out how that resolves the issues mentioned earlier:

• A container has a very small footprint. The main aim of containerization is to break a solution down into small chunks, called a microservices architecture (MSA). With a container, a failed service can be rebuilt/built in nanoseconds and fully running in seconds. If the image used by the container is properly designed, it can even take a smaller amount of time. Containers use a lightweight operating system with a very small footprint.
• Complexity of the solution. A basic architectural principle of containerization is simplicity. By running only what is needed by the application or MSA the container represents, there is no need to run a complete operating system and no need to know or care about the underlying host, making the container portable. A container is everything the app or MSA needs and nothing that it doesn’t.
• Cost of horizontal scaling and limitation of the vertical scaling. One of the biggest benefits of containerization is scalability, as containers are built to run granular and standalone applications. If there is a need to scale due to load, more containers can simply be added – delivering the same horizontal scaling as a VM in a cost-efficient manner. Vertical scaling is no longer necessary with containerization, either.

Do Containers Replace VMs Completely?

Not entirely. To answer that question, let’s …