In-Depth

Explaining Virtual Machines and Containers with Three Slides

• By Tom Fenton
• 10/08/2025

I recently had the opportunity to do a short presentation where I needed to explain the differences between virtual machines (VMs) and containers. The audience had a general understanding of computer concepts but limited knowledge of OS virtualization and container technology.

After noodling it around for a while, I decided to challenge myself and use only three slides to explain the concept to them. The presentation was well-received, so I thought I would share it.

The first slide showed a pickup with a large wooden box in the back of it.

I explained that the pickup truck is analogous to a stand-alone computer running an operating system (OS). It could be a desktop OS like Windows 11, which is the one they use on their laptops, or it could be a server operating system, such as Windows Server or one of the Linux variants.

The wooden crate in the truck's bed represents the workload (applications) running on the computer. For a desktop OS, this would involve working with office documents, browsing the internet, watching videos, using unified communications, or running any other applications.

Just as with trucks, computers have also become more powerful over the years. For example, my first truck, a 1965 F-100, had a 240-cubic-inch inline six-cylinder engine that had 150 horsepower. Today, you can purchase an F-150 Raptor that features a V8 engine and produces 720 horsepower. Interestingly enough, the 1965 truck gets about 17 MPG while the Raptor gets 15 MPG. This pales in comparison to the significant advancements in computer power, as we now have computers with 32 cores and terabytes of RAM.

I then discussed how VMs and containers are both technologies that enable the execution of multiple isolated environments on a single physical machine. However, there are some key differences that I will discuss.

Virtual Machines
At the end of the 20th century, some exceptionally talented individuals developed the technology that enabled multiple operating systems and, more importantly, their corresponding applications to run simultaneously on a single computer. The software that allows this is called a hypervisor. This enabled the computers to use their increased capacity. These operating systems do not run directly on bare metal and are, therefore, referred to as VMs. VMs are complete computer systems that are emulated in software. They have their own operating system, virtual hardware, and virtual memory. This means that each VM is entirely independent of the other VMs on the same machine.

This would be analogous to a single truck trailing multiple trucks and their payloads.

Now, let's dive a little bit deeper into hypervisors and VMs.

There are two different types of hypervisors. Type 1 hypervisors, also known as bare-metal hypervisors, run directly on the physical hardware of a host machine without requiring an operating system. On the other hand, Type 2 hypervisors, also known as hosted hypervisors, run on top of an existing operating system, just like any other application, leveraging its resources and functionalities. They are typically more flexible and easier to set up but may offer lower performance compared to Type 1 hypervisors due to the additional layer of abstraction.

There are three major camps of type 1 hypervisors: VMware ESXi, Microsoft Hyper-V, and KVM. ESXi is a proprietary technology from VMware that is a popular choice for enterprise environments. Microsoft Hyper-V, integrated with Windows Server, is not as well accepted in enterprises. It is used by some companies that already utilize Microsoft's ecosystem. Linux KVM (Kernel-based Virtual Machine) is an open-source hypervisor that leverages the Linux kernel's capabilities, offering a cost-effective and flexible solution for a wide range of use cases. Each of these hypervisors has its strengths, catering to different organizational needs and preferences.

Type 2 hypervisors, such as VMware Workstation and Oracle VirtualBox, are typically not used for enterprise workloads; instead, they are commonly employed by developers and home users.

Containers
Recently, some other smart folks put their heads together and asked themselves an interesting question: why do we even need the VM? Why can't we package and run the application in a secure, isolated environment? This paved the way for the emergence of containers.

Due to their structure, containers are lightweight and use fewer resources than VMs. They share the host machine's operating system kernel and only have their application and libraries. This makes them more efficient to use than VMs.

This brings us to our third photo, a truck (the operating system) just hauling boxes, which represents the containerized applications.

To initiate and manage containers, many technologies have been developed, with Kubernetes and Docker being the most prominent among them.

Docker brought container technology to the mainstream and revolutionized containerization by providing a simple and efficient way to create, deploy, and run applications inside containers. It offers a lightweight and consistent runtime environment, allowing developers to package applications with all their dependencies and run them anywhere.

Kubernetes has become the dominant choice for most enterprise container deployments due to its robust orchestration capabilities. It automates the deployment, scaling, and operation of containerized applications, which is essential for handling complex and distributed systems. This automation is a key factor driving its popularity in enterprise environments, as it significantly reduces the operational overhead associated with managing large-scale deployments. Furthermore, its open-source nature and strong community support contribute to its continuous improvement and integration with various tools and platforms, enhancing its versatility and appeal.

What Should You Use?
Deciding whether to use a non-virtualized environment, VMs, or containers depends on your specific use case. However, here are some general guidelines to follow.

• Resource and performance: Both VMs and containers have a slight amount of overhead associated with them. VMs are more resource-intensive than containers, as they run an operating system in addition to the application. In contrast, containers share the host machine's kernel and have fewer layers of abstraction.

• Portability: Operating an OS and application on a standalone server lacks portability; once instantiated, they stay on the same hardware. In contrast, containers and VMs can be transferred seamlessly from one server to another, typically with minimal disruptions.

• Management: The management of these three technologies depends on scale. Managing a couple dozen or even a hundred stand-alone servers is manageable, but as you scale up, the complexity increases. Similarly, managing a few hundred VMs is straightforward; however, when thousands or tens of thousands of applications need to be managed, using a container management system like Kubernetes is the most effective approach.

What Are They Typically Used For?
Although I haven't emphasized it in this presentation, there is a place for stand-alone servers in a data center. Large, complex, and highly critical applications, such as databases, are often run on standalone servers due to performance and isolation reasons.

However, the majority of enterprise applications run on VMs and containers. VMs are typically used for applications that do not consume the full resources of a single stand-alone server. Testing a developing applications that need to run on various desktop and server operating systems is common. They are almost exclusively used for running remote desktops.

Containers have become extremely popular, and many new enterprise applications are specifically built to run on them. Containers also offer portability, enabling developers to develop and test applications on various platforms before deployment, ensuring compatibility. They facilitate continuous integration and delivery (CI/CD), allowing frequent updates and improvements without significant downtime or disruption to user experience.

Although I have focused on the enterprise use of containers, I also need to acknowledge their use in other fields, such as Smart TVs. On Smart TVs, Containers allow multiple applications to run simultaneously while keeping each isolated and secure. This isolation prevents any single application from consuming all resources or causing instability.

Ultimately, the best way to choose between VMs and containers is to consider your specific needs and requirements carefully.

By using these three pictures and approximately 1,300 words, I was able to contrast the differences between stand-alone systems, VMs and containers.