Two Trucks: Explaining VMs and Containers

Virtual machines and containers solve different problems. The easiest way I have found to explain the difference is with two trucks.

Most teams I have worked with understand the technical details of virtual machines and containers. The hard part is explaining, in a way that sticks, why two technologies that both “isolate workloads” behave so differently in production.

Diagrams with stacked boxes are accurate, but they rarely land with anyone outside infrastructure. What finally worked for me was a picture everyone already understands: a truck on the highway carrying cargo. Same truck, two kinds of cargo, two very different outcomes.

Below is that analogy, followed by four retail and supply chain scenarios that show when each technology is the right call.

Truck one: the car carrier

Picture a car carrier on the highway. It holds several cars, and each one is a complete vehicle with its own engine, steering, and dashboard. Yet none of them is driving. The carrier does all the moving, while the deck and straps decide where each car sits and keep them from bumping into each other.

That is a virtual machine. A VM is a software defined computer running on physical hardware that a hypervisor (KVM, VMware ESXi, or Hyper-V) divides and manages. The mapping:

• The truck chassis and engine is the host hardware: CPU, memory, storage, and network cards.
• The deck and straps are the hypervisor. It hands each VM its share of the hardware and keeps them isolated.
• Each car is a VM with its own complete guest operating system, including its own kernel, drivers, and system services.
• The cargo on each car’s roof is the application.

The strength of this design is that each car is a full vehicle. A Windows VM and a Linux VM can ride side by side on the same server, and a problem inside one stays inside it. The cost is also that each car is a full vehicle. Every VM carries an engine it never uses for driving: a whole operating system that has to boot, consume memory, and be patched.

Truck two: the container truck

Now swap the cars for shipping containers. They have no engines and no steering. They simply hold cargo and rely on the truck’s engine to move. Because they are lighter and smaller, the same truck carries more of them and gets moving faster.

That is a container. A container packages an application with everything it needs to run (code, runtime, system tools, and libraries) into a portable image. Instead of virtualizing hardware, containers virtualize at the operating system level:

• The truck chassis and wheels are the physical hardware, or very often a VM rented from a cloud provider.
• The cab and engine are the host operating system. Every container shares its kernel.
• The flatbed and locking clamps are the container engine, such as Docker or CRI-O.
• Each container holds one application plus its binaries and libraries, kept apart from the others by Linux namespaces and cgroups.

With no guest operating system to boot, a container starts in milliseconds to seconds and uses megabytes of memory rather than gigabytes. The tradeoff is that every container shares one kernel. A Linux host runs Linux containers, and isolation is strong but not as strong as a hypervisor boundary.

What the extra engines cost?

The difference between the two trucks shows up directly in resource usage.

When the car carrier wins?

The legacy warehouse system that will not move

A grocery distributor runs a warehouse management system that its vendor supports only on an older version of Windows Server. It depends on specific drivers for barcode scanners and label printers. The same facility also runs Linux based inventory services.

Containers cannot help here. All containers on a host share one kernel, so a Windows workload and Linux services cannot run side by side as containers on the same host. Putting the warehouse system in its own VM lets the distributor retire aging servers and consolidate hardware without rewriting or recertifying software the warehouse depends on every day.

The order database that cannot go down during holiday season

An omnichannel retailer’s order management database handles online orders, buy online pick up in store requests, and inventory reservations for every store. In the middle of holiday peak, the physical host it runs on reports early signs of hardware failure.

Shutting the database down would stop order processing at the most expensive moment of the year. Because a VM’s entire state lives in software, the hypervisor can live migrate it to a healthy server. It copies the VM’s memory while the database keeps taking orders, recopies the pages that changed, then pauses the VM for a few milliseconds to move the last pages and the CPU state before resuming it on the new host. Customers keep checking out, and the team repairs the failing server afterward.

When the container truck wins?

The flash sale that arrives all at once

An online retailer splits its storefront into microservices: product search, cart, pricing, and checkout. When a holiday promotion goes live, traffic to search and checkout jumps within minutes while the other services barely notice.

A container orchestrator such as Kubernetes launches extra instances of only the services under pressure, then removes them when demand settles, so the retailer pays only for the capacity it uses. New containers start in seconds when the cluster has spare capacity. Adding new nodes takes longer, which is why teams usually scale up ahead of a planned sale. Doing the same with VMs means booting a full operating system for every new instance.

The update that has to reach every store

A retail chain runs an inventory service on edge servers in hundreds of stores and distribution centers. It processes handheld scanner data and syncs stock levels with headquarters. Every location needs the same version, and a bad release has to be reversible fast.

The team builds one container image in its CI/CD pipeline, validates it in staging, and rolls that same image out to stores in waves, watching each wave before starting the next. After the first deployment, an update only sends the image layers that changed, which matters on thin store networks. If a defect appears, every site rolls back to the previous image version within minutes. With VMs, the same rollout would mean shipping and patching operating system disk images of many gigabytes to each location.

In practice, you load containers onto the car carrier

The real answer in most retail stacks is not one truck or the other. It is both. Most production Kubernetes clusters run on VMs from a cloud provider. The VMs give strong isolation between environments and teams, and the containers inside them give fast scaling and consistent deployment.

So the useful question is not “VMs or containers?” It is which layer each workload belongs on. Legacy, OS bound, and stateful systems that cannot afford a restart usually sit best in VMs. Stateless services that need to scale quickly or ship often usually sit best in containers, running on top of those same VMs.

Which truck carries most of your production workloads today: the car carrier or the container truck?