The spectrum of isolation: From bare metal to WebAssembly

Summary

Table of Contents Ever had that dreaded “but it works on my machine!” moment? The culprit is often a subtle difference in the execution environment—the “stage” where your code performs. You might be dealing with a binary linked against the wrong glibc, a Python wheel built for a different architecture, or a kernel feature quietly missing in production. These invisible discrepancies are what turn a successful local build into a deployment disaster. Getting the environment right is crucial for writing, testing, and shipping software reliably. But the landscape is crowded with terms like virtual machines (VM), containers, virtual environments, and more. What’s the difference, and which one should you use? We’re going to trace the evolution of the execution environment. We’ll start with raw hardware and work through VMs, containers, and the various ways we isolate code at the operating system (OS) and language level. Along the way, we’ll break down the trade-offs for each approach. By the end, you’ll know exactly which tool to grab for your next project. The history of computing is largely a history of resource sharing without chaos. Early systems ran one workload per machine. Today, a single server might host thousands of isolated applications owned by different teams. The unifying idea behind this evolution is isolation: separating code, dependencies, and resources so they don’t interfere with one another. But isolation is not binary. It exists on a spectrum—hardware, kernel, process, filesystem, language runtime. Each execution paradigm chooses a different point on that spectrum. Rule of thumb: any layer below your chosen isolation boundary must already be compatible—containers won’t fix a kernel mismatch, and virtual environments won’t fix a missing system library. We’ll move from the heaviest to the lightest abstractions. This is the foundation. One machine, one operating system, running your code directly on the hardware. Hardware (CPU, memory, Disk,…): Uniquely p...