Simulation, Emulation, Virtualization, and Containers: The Restaurant Metaphor

“So what’s the difference between a container and a virtual machine?”

I get this question a lot, usually from someone smart who has been nodding along in meetings without quite wanting to admit they’re fuzzy on it. And the honest answer is that most explanations make things worse. They reach for “hypervisor,” “kernel sharing,” and “hardware abstraction” in the first sentence, and now the person has four new terms to be confused about instead of one.

There’s a deeper question hiding behind the container-versus-VM one: what’s actually the difference between simulation, emulation, virtualization, and containerization? People mash these four together all the time. They’re four different answers to the same problem, which is running something in an environment it was never designed for.

I care about this distinction because I care about understanding what I run. If you can’t say which of these four a tool is doing, you can’t reason about its performance, its isolation, or what breaks when it falls over. So let me explain the whole set the way that finally made it stick for me: with restaurants.

The Restaurant Metaphor

Imagine you want to eat Japanese food. You have four options:

1. Simulation: The Cooking Show

You watch a Japanese cooking show. The chef demonstrates how to make sushi, explains the techniques, shows the ingredients being cut and assembled. You can see everything that would happen if you were eating at a Japanese restaurant.

But you’re not eating anything. There’s no real food. What you have is a model of the experience. Great for understanding, useless for hunger.

That’s simulation: you build a model of something to study how it behaves, and you never run the real thing.

In tech terms, a flight simulator models how an airplane behaves. Brilliant for training pilots, and there’s no actual airplane anywhere in the loop. A circuit simulator does the same for electronic components: it predicts how they’d behave, with zero real electronics on the bench. The point of a simulation is the prediction, not the artefact.

2. Emulation: The Japanese Restaurant in Amsterdam

You go to a Japanese restaurant in Amsterdam. The Dutch chef learned authentic Japanese techniques. They import Japanese ingredients. They’ve rebuilt the Japanese kitchen equipment. They plate the food on Japanese ceramics.

Everything is designed to behave exactly like a Japanese restaurant in Tokyo. Done well, the result is hard to tell apart from the real thing: same taste, same presentation, same experience.

But you’re still in Amsterdam. The whole thing is one system faithfully pretending to be another, by copying every detail of how the original works.

That’s emulation: you make one system behave exactly like a different system by replicating its behaviour in software.

In tech terms, run a Game Boy emulator on your laptop. The laptop has no Game Boy hardware anywhere inside it, so the emulator software stands in for every Game Boy component: the CPU, the graphics chip, the sound chip. The games can’t tell. They genuinely believe they’re running on a real Game Boy, and they run for real, not as a model.

3. Virtualization: The Hotel Restaurant

You stay at a hotel with several restaurants under one roof: Japanese, Italian, French, Indian. Each runs on its own. Separate kitchens, separate chefs, separate menus.

What they share is the building itself: the electricity, the water, the ventilation, the cleaning crew. Hotel management hands out the resources, deciding how much space, power, and staff each restaurant gets.

Every one of these is a real, fully working restaurant. None of them is pretending to be anything. They’re just splitting the underlying infrastructure efficiently.

That’s virtualization: you run several complete operating systems on one set of hardware, with a thin layer underneath that hands out the resources.

In tech terms, run Windows and Linux at the same time on one physical server. Each gets its own full operating system, and they share the CPU, memory, and storage. The hypervisor plays hotel management here, keeping them from stepping on each other.

4. Containers: The Food Court Kitchen

You go to a food court. One big kitchen in the back, and a bunch of vendors sharing it. Same ovens, same prep tables, same refrigerators.

Each vendor still gets their own section: their own ingredients, their own recipes, their own pots and pans. The sushi vendor can’t reach into the pizza vendor’s mise en place. They’re walled off from each other while sharing the kitchen itself.

That’s cheaper than building every vendor a whole separate kitchen. All a vendor really needs is their own stuff, the ingredients and tools specific to their food.

That’s containerization: applications run in isolated spaces on top of one shared operating system kernel, each carrying its own dependencies and libraries.

In tech terms, Docker containers on a Linux server. Each container has its own filesystem, its own installed packages, its own app. They all share one Linux kernel. The container runtime plays food court management, keeping everyone in their lane.

Comparison Table

When to Use What

Simulation

Use when:

• You need to understand or predict behavior without running the real thing
• Testing is dangerous, expensive, or impossible (nuclear reactors, space missions, epidemics)
• You’re designing something that doesn’t exist yet

Don’t use when:

• You need actual results, not modeled results
• You need to run real software

Examples:

• Weather modeling
• Flight simulators
• Circuit design tools
• Financial modeling
• Physics simulations

Emulation

Use when:

• You need to run software from a completely different platform
• The original hardware is obsolete, rare, or unavailable
• Exact behavior replication is more important than speed

Don’t use when:

• Performance matters (emulation is slow)
• You can use virtualization instead (much faster)

Examples:

• Running old console games (SNES, PlayStation)
• Running ARM software on x86 (Apple Rosetta 2)
• Preserving legacy software when hardware dies
• Mobile app development (Android emulator)

Virtualization

Use when:

• You need to run multiple different operating systems on one machine
• Full isolation between environments is required
• You need to run a different OS than your host (Windows on Linux, etc.)
• Each environment needs different kernel versions

Don’t use when:

• All your workloads use the same OS (containers are more efficient)
• Maximum performance is critical
• Resources are very limited

Examples:

• Running Windows and Linux on the same server
• Development environments matching production
• Testing on different OS versions
• Multi-tenant hosting with full isolation

Containers

Use when:

• All workloads can share the same OS kernel
• You need lightweight, fast isolation
• You’re deploying many similar applications
• Resource efficiency is important
• Fast startup times matter

Don’t use when:

• You need to run a different OS (can’t run Windows containers on Linux kernel)
• You need absolute security isolation (VMs are more isolated)
• Your software requires kernel modifications

Examples:

• Microservices architectures
• CI/CD pipelines
• Local development environments
• Kubernetes workloads
• Scaling web applications

The Layering Reality

In practice, these technologies are often combined:

flowchart TD
    subgraph layers["Technology Layers"]
        App["Your Application<br/>(Container)"]
        Runtime["Container Runtime<br/>(Docker/containerd)"]
        GuestOS["Guest OS - Linux<br/>(Virtual Machine)"]
        Hypervisor["Hypervisor<br/>(Virtualization)"]
        HostOS["Host OS"]
        Hardware["Physical Hardware"]
        App --> Runtime
        Runtime --> GuestOS
        GuestOS --> Hypervisor
        Hypervisor --> HostOS
        HostOS --> Hardware
    end

You might run containers inside virtual machines inside physical servers. Every layer costs you a bit of overhead and buys you back capability and isolation. Worth knowing which trade you’re making at each level.

Cloud providers stack it like this constantly. Your “server” is a VM on their hardware, and you run your containers inside that VM. The layering is exactly why I want to understand these distinctions: when latency spikes, I want to know which floor of that building it came from.

Common Confusions

“Docker is a virtual machine”

No. Docker containers share the host’s kernel, VMs bring their own. That single difference is why a Docker container starts in seconds with no kernel to boot, while a VM takes minutes to come up.

“Emulation is just slow virtualization”

No, they solve different problems. Emulation translates one architecture into another (Game Boy → PC). Virtualization runs the same architecture more efficiently (x86 → x86).

A PC virtualizes Linux on Linux very efficiently. But it has to emulate a Game Boy, because there’s no Game Boy hardware anywhere to virtualize in the first place.

“Containers are secure isolation”

Partially. Containers give you process isolation, but they share a kernel. A kernel vulnerability can become a container escape. VMs isolate harder precisely because they don’t share that kernel.

For high-security or untrusted workloads I still reach for VMs. For most of what I run, containers are fine, and I make that call deliberately rather than by default.

“Simulation and emulation are the same”

No. Simulation models behaviour approximately. Emulation replicates behaviour exactly.

A flight simulator simulates airplane physics to predict and teach. A Game Boy emulator copies the exact hardware behaviour, and the games on it run for real.

Wrapping up

Next time someone asks you to explain these, reach for the food:

• Simulation: a cooking show. You see what would happen, nothing actually runs.
• Emulation: a Japanese restaurant abroad. A full copy of how something else works.
• Virtualization: hotel restaurants. Real, complete, isolated kitchens sharing one building.
• Containers: a food court. Isolated vendors sharing one kitchen.

Each earns its place. Simulation when you want to model something without running it. Emulation when you need to run foreign software on hardware that was never meant for it. Virtualization when you genuinely need different operating systems side by side. Containers when you want to run a lot of similar apps without paying for a full OS each time.

The reason I bother keeping these straight isn’t pedantry. It’s that knowing which one you’re running tells you what to expect when it breaks, and that’s the whole game with infrastructure you actually own. Now you can explain it to anyone, no hypervisor vocabulary required.