Container vs. Hypervisor: What’s the Difference?

From the OSI model to programming, understanding tech often comes down to understanding different layers of abstraction. That sentiment holds true for virtual machines (VMs) and containers as well.

In fact, focusing on what is abstracted away by virtual machines and containers can help make containers conceptually "click" for you. In short:

• Virtual machines and hypervisors abstract away hardware and enable you to run operating systems

• Containers (technically container engines) abstract away operating systems and enable you to run applications

Of course, that's a high-level and simplified explanation. To understand which tool is right in a given use case, just think about what each technology does. Here, we'll explore the topic in more depth — and provide you with a crash course on virtual machines versus containers.

Virtual Machines Explained

VMware provides one of the more elegant virtual machine definitions when they describe a VM as "a software computer." There are two basic ways to run virtual machines: using "Type 1" virtualization or "Type 2" virtualization.

In professional production environments, you're much more likely to encounter Type 1 virtualization. With Type 1 virtualization, a lightweight operating system known as a hypervisor is installed on a physical computer or server. The physical box is often called "bare metal" and Type 1 hypervisors are often called "bare metal hypervisors." Common examples of bare metal hypervisors are VMware's ESXi, KVM (Kernel-based Virtual Machine), and Microsoft's HyperV.

Once you install a bare metal hypervisor, you can then install multiple "traditional" operating systems on top of it. For example, with ESXi installed, you could run Windows Server 2016, CentOS 7.6, and Ubuntu 18.04 on the same hardware. ESXi provides virtual compute, storage, and memory to the operating systems.

The operating systems use these "virtual" resources just as they would physical resources. This is the abstraction of hardware I referred to earlier. From here, you can install applications and services (e.g. Active Directory or a web server) onto the operating systems.

Type 2 hypervisors, a.k.a. "hosted hypervisors," operate a bit differently. As opposed to being installed on top of bare metal hardware, they're installed on top of a standard operating system. Oracle's VirtualBox and VMware's VMware Player are popular examples of hosted hypervisors.

With a hosted hypervisor, you can run a second isolated operating system from within your main operating system. Suppose you want to run Linux Mint, but don't want to uninstall Windows from your PC or use dual boot. With a hosted hypervisor you can run an isolated instance of Linux Mint within your Windows PC.

Side note: For those familiar with Windows Server Operating Systems, describing HyperV as a Type 1 hypervisor may be confusing. It seems like HyperV runs on top of another operating system, which would make it a Type 2. However, when you get down to the nuts and bolts, HyperV runs beneath the operating system and accesses the hardware. The answers in this SuperUser post do a good job explaining the details.

Looking for a deeper dive on virtualization and hypervisors? Check out Jacob Moran's Intro to Virtualization course. In addition to providing information on certifications and terminology, Jacob explores practical topics like picking the right hypervisor.

Benefits of Virtual Machines

Now that we've established what virtual machines are, we can dive into the benefits. At a high-level, the main benefits of virtualization (relative to running on bare metal) are:

• More efficient use of hardware. Being able to virtualize servers means being able to run more operating systems on your hardware. This leads to efficiencies in everything from maintenance to energy costs and rack space to cooling. At a large scale, the efficiencies of virtualization have helped contribute to the economies of scale associated with the cloud.

• Easier and faster management & provisioning. It is much easier and faster to spin up and down virtual servers than provision new hardware. Creating backups and server snapshots is much simpler as well.

• Improved disaster recovery. Because it is easy to create backups and recover to snapshot images, disaster recovery is easier and faster.

• Simplified testing. Testing in production isn't a great idea. Dedicating a server to testing isn't too efficient if you have to test many different operating systems. With VMs, you can run a logically isolated operating system that enables you to test relatively freely.

Containers Explained

You likely understand that containers are a big part of DevOps, cloud native software, and microservices. Given the popularity of those things, you probably also know containers are an important part of modern IT.

However, once you understand virtual machines, you may have some difficulty conceptualizing why containers are useful. VMs abstract away hardware, so wrapping your head around why we need more abstraction is tough. Fortunately, once you dive into how they work, it starts to make sense.

Containers package an application and all the underlying dependencies together. This container package can then be run anywhere a container engine is installed.

As we can see, containers sit on top of a container engine (in this example LXC), which sits on a host operating system. The host operating system can be a VM or running on bare metal. This configuration allows you to run multiple logically isolated apps and services efficiently. One important thing to note is the underlying kernel of the host operating system is shared by all the containers.

While containers are generally used with *nix operating systems, they are available for Windows as well. If you're looking to dive into containers and Windows, check out our Implement Windows Containers training.

Benefits of Containers

You'll find that containers have grown in popularity because they go a long way toward enabling DevOps methodologies. The major upsides of containers (relative to VMs) include:

• Containers are lightweight. Containers use only the binaries and libraries they need. This means they boot significantly faster than VMs. In the world of web applications, boot times in seconds versus boot times in minutes can make a world of difference. Being more lightweight also means less hardware and fewer operating systems are needed.

• Containers are portable. Anywhere you can run a container engine, you can run a container. What this means is arguments over an environment being the cause of an issue with an app should be reduced. If it ran for development on their container, it should run for QA, and it should run in production.

• Containers enable microservices. In short, microservices are small services that communicate with one another to create a larger application or service. By decoupling individual microservices testing becomes easier, single points of failure are reduced, and development velocity is increased. For a deeper dive on the topic, check out AWS's What are Microservices? article.

Looking for a training to help you get started with containers? Check out Shawn Power's Docker training.

Understanding Container Lingo

If you're new to containers, there are a number of new terms you should learn sooner rather than later. Here are a few of the most common:

• Container. To quote Docker, a container is "a standardized unit of software." It includes all the dependencies an app needs. A container requires a container engine to run.

• Container engine. Container engines are what enable containers to run. Examples of container engines include Docker and LXC. For more on the nuts and bolts of container engines, check out So, What Does a Container Engine Really Do Anyway? on CrunchTools.

• Cluster. A group of containers managed by a "master" machine.

• Pods. Groups of containers within a cluster that serve a given purpose and share resources. Check out this Google Cloud Platform (GCP) blog for a deeper dive on pods and clusters.

• Kubernetes. Also known as K8s, Kubernetes is a container management and orchestration tool. It enables management of clusters of containers. Alternatives to Kubernetes include Docker Swarm and Apache Mesos.

These definitions only scratch the surface and there's plenty more to learn. However, understanding that containers are the base unit, clusters and pods are groups of containers, and tools like K8s enable management is a good starting point.

When Should You Use Containers vs. Virtual Machines?

At this point, you've probably realized that containers and VMs aren't mutually exclusive. You may want to run them together in some cases. In others, it may make sense to use one or the other. Here we will review the comparative advantages for those either/or cases.

It often makes sense to use virtual machines for use cases like:

• Maintaining consistency and compatibility in existing environments. Simply put, many environments simply aren't using containerization today. Servers run as VMs and there may not be compelling reasons to move away from that. In those environments, pushing a shift to containerization might not make business sense yet.

• Running multiple applications together. Sometimes, you simply need a server or computer to run multiple apps. VMs fill this need nicely.

• Ensuring complete logical isolation. Remember, containers installed on a given host operating system all share that kernel. From a security perspective, they are not as logically isolated as VMs. If isolation is important and you're choosing between VMs and containers, VMs may be the right choice.

Containers can be useful for:

• Enabling microservices and DevOps. Containers are at the core of DevOps and microservices. If you are in an environment that embraces DevOps methodologies, containers can often help. This is because they are portable and fast.

• Web applications- Many web apps are moving to a microservices approach. If you are building web applications, moving to a microservices architecture that leverages containers has a lot of upside.

• Environments where speed is a must. Generally speaking, containers boot significantly faster than VMs. This enables faster testing and recovery when a reboot is required. If all else is equal and you need something fast and lightweight, go with a container.

Final Thoughts

As we have seen, containers and virtual machines are technologies that solve two different problems. If you need a way to run a full operating system, a VM makes sense. If you need to deliver a service in a lightweight and portable manner, a container can be a good fit.

Remember, the underlying technology is just a means to an end. As an IT pro, it's up to you to pick the right tool for the job. The better you understand the underlying technologies, the better you can pick a solution that makes sense.