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 both virtual machines (VMs) and containers.
In fact, focusing on what is abstracted away by virtual machines and containers can help the concept "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 definitions of 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 where 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 include VMware's ESXi, KVM (Kernel-based Virtual Machine), Microsoft's HyperV, and modern hardware-accelerated hypervisors used in public clouds, such as the AWS Nitro Hypervisor.
Once you install a bare-metal hypervisor, you can run multiple operating systems on the same physical server. For example, with ESXi installed, you could run Windows Server 2022, Ubuntu, or Rocky Linux side by side. The hypervisor provides each VM with virtual compute, storage, and memory, allowing them to operate as if they were running on dedicated hardware.
The operating systems use these "virtual" resources just as they would physical resources. This is the hardware abstraction we discussed earlier. From here, you can install applications and services (e.g., Active Directory or a web server) onto the operating systems.
Type 2 hypervisors, aka "hosted hypervisors," operate a bit differently. Unlike bare-metal installations, they're installed on 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 on your Windows PC.
Side note: For those familiar with Windows Server Operating Systems, describing Hyper-V as a Type 1 hypervisor may be confusing. Hyper-V runs on top of another operating system, making it a Type 2 hypervisor. However, when you get down to the nuts and bolts, Hyper-V runs beneath the operating system and accesses the hardware.
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 also explores practical topics such as choosing 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: Virtualizing servers lets you run more operating systems on the same 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 and Provisioning: It is much easier and faster to spin up and down virtual servers than to 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, enabling you to test more freely.
Containers Explained
You likely understand that containers are a big part of DevOps, cloud native software, and microservices. However, you may find it difficult to conceptualize 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 containers 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.
Containers run on top of a container engine such as containerd, CRI-O, or Docker. Today’s Kubernetes-based systems typically rely on containerd or CRI-O under the hood, while Docker remains a popular tool for local development. The host operating system can be a VM or run on bare metal.
This configuration allows you to run multiple logically isolated apps and services efficiently. One important thing to note is that all the containers share the host operating system's kernel.
While containers are most commonly used on Linux, Windows containers are available as well and have matured significantly in recent Windows Server releases.
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:
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 measured in seconds versus minutes can make a world of difference. Being more lightweight also means less hardware and fewer operating systems are needed.
Portable: Anywhere you can run a container engine, you can run a container. What this means is that arguments over an environment being the cause of an app issue should be reduced. If it ran in development on their container, it should run in QA and in production.
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.
Security Features: Built-in security controls help protect applications throughout deployment. Image scanning, signed container images, runtime monitoring, and policy enforcement tools make it easier to detect vulnerabilities early. While containers don’t replace the isolation of full VMs, these features add strong safeguards for most production environments.
Looking for 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, CRI-O, and enterprise tools like Podman.
Cluster: A group of containers managed by a central control plane.
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, it is the leading container orchestration tool for deploying and managing container clusters. Most modern environments run Kubernetes via managed services like EKS, GKE, or AKS, and typically rely on containerd or CRI-O under the hood. Alternatives like HashiCorp Nomad or lightweight Kubernetes distributions such as K3s offer simpler options for smaller or edge deployments.
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 either one. 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: 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.
Some environments now use lightweight microVM technologies such as AWS Firecracker or Kata Containers, which provide VM-level isolation at container-like speeds. These sit in between traditional VMs and containers and are common in serverless or multi-tenant environments.
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 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 offers significant 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 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, portable way, 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.
Want to learn more? Sign up for a free trial of CBT Nuggets and start training today.
delivered to your inbox.
By submitting this form you agree to receive marketing emails from CBT Nuggets and that you have read, understood and are able to consent to our privacy policy.