The Hitchhiker’s Guide to Telco Transformation - Part 5
Containers vs VMs
In some of my previous blogs I discussed the difference between SaaS, IaaS and PaaS. Similar to the confusion between the aforementioned terms, is the confusion between containers and VMs (virtual machines). It seems to me, that of late the industry is rife with discussion about containers and VMs, and their pros and cons. Lately the container protagonists seem to be leading the pack, with every company, who’s any company, using them.
In fact a survey by 451 research has suggested that container adoption will grow by 40% every year until 2020. But just because their popularity is on the rise, does not mean that VMs are dead. So what exactly is the difference between the two and when should each be used? This is the subject of the blog before you.
While VMs and containers are often compared and contrasted in their ability to serve the virtual world, they are each designed slightly differently. Meaning that they are built with different building blocks.
Infrastructure - Both run on servers (‘bare metal’ for some of you), which means any ‘white box’ processor. And both use some sort of operating system to interconnect with the functions that need to be run.
Hypervisor/Engine layer - In the VM architecture, a hypervisor is needed to run and manage the different virtual machines (such as KVM, ESX). A hypervisor is the software, firmware or hardware that creates and runs virtual machines. There are two type of hypervisors: 1) native hypervisors – can run on the ‘bare metal’ service (like ESXI) or 2) hosted hypervisors which run on the server OS.
In the container architecture the container engine runs over the infrastructure OS (Linux, Ubuntu, or CentOS for example).
The VM/Container layer – Each VM is independent and requires a guest OS, Bins and libraries and an application on top. Which means that VMs requiring different OS can be run on the same machine. But this also means that each VM can be many gigabytes in size.
Containers on the other hand all run upon the general infrastructure OS (like Linux or Windows) and sometime can share bins and libraries. Shared components are often ‘read only’ and so exceptionally light.
In other words a VM is a stand-alone application that can run inside a virtualized environment, and it runs separately from every other app that's running on this big machine. So you might use VMs to run different application which are dependent on different OS and resources, all on the same machine.
A container uses a shared infrastructure + OS + bins and libraries to run different applications separately but using the same resources. The container separates these apps so that they don't see each other. They're in their own little world. Here you would run different apps that require the same OS and some of the same resources (dependencies) on the same machine.
Let me give you an example
Let's say I want to run a few web applications. They are all Linux based, but 1 runs on PHP 5 and the other runs on PHP 4. Containers can handle various apps running on the Linux OS by utilizing the shared resources and isolating, or separating, the different dependencies.
So how do the two compare?
So when should you use container and when should VMs be used?
If you are looking to run multiple instances of the same app, or multiple instances of apps which run on the same OS – choose containers. Also if your apps are built with microservice architecture (which means that the components of the app are loosely coupled), then working with containers, will be intuitive.
If you are looking to run multiple apps which require different OS, or if security is a primary concern – VMs are the better choice.
In the end, I believe the majority will run both.
Join me next time as we travel to new destinations on our journey to telco transformation.