Physical Servers vs VMs vs Containers vs Serverless

A virtual machine (VM) runs a complete guest operating system on virtualised hardware provided by a hypervisor. A container runs as an ordinary process on the host's kernel, isolated by kernel features such as namespaces and cgroups, and packaged with its application and libraries in an image. Containers are lighter and start in seconds or less; VMs give stronger isolation. Most cloud platforms run containers inside VMs, getting both.

From physical servers to serverless

Where code runs has changed steadily, each step trading some control for efficiency and convenience: physical servers, then virtual machines, then containers, then serverless. Each still has its place.

Physical servers

Running "on the metal": a real machine that hosts the operating system, applications and data, built to store, process and serve data around the clock.

• Pros: complete control over hardware, software and configuration; top performance, since nothing is shared with other workloads.
• Cons: expensive to buy, run (power, cooling) and upgrade; slow to scale, because more capacity means buying and installing hardware.
• When to use: high-performance computing and workloads that need full control, such as large enterprises running heavy big-data analytics or HPC jobs, latency-critical trading systems, or very steady workloads where owning hardware is cheaper than renting.

Virtual machines

A VM emulates a whole computer. Several VMs run side by side on one physical server, each with its own operating system and applications, and possibly different operating systems.

• Pros: isolation (one VM crashing doesn't affect the others) and much better utilization of the physical server.
• Cons: some performance overhead from translating between the guest and host; resource-heavy, since each VM carries a full copy of an operating system.
• When to use: running several isolated systems on one server, for example a development environment testing different operating systems or software versions, or legacy apps that need a specific OS.

Containers

A container packages an application and its dependencies into one self-contained unit that runs the same anywhere. It doesn't carry a full operating system: containers share the host's kernel, which makes them much lighter and faster to start than VMs.

• Pros: portability (the same image runs on a laptop, in CI and in production) and efficiency (no guest OS per app).
• Cons: weaker isolation, since containers on one host share a kernel, which can expose security vulnerabilities; operational complexity, because many containers need an orchestrator such as Kubernetes.
• When to use: deploying microservices, and apps that must scale up and down quickly, such as web apps with variable traffic.

In short: a VM bundles the app, its libraries and a full guest OS on virtual hardware; a container bundles the app and its libraries and shares the host OS kernel. Choose VMs for full isolation or a specific OS; choose containers for efficiency, speed and scale in cloud-native systems. Julia Evans' well-known comic sums up the differences:

• A container is a group of processes: one Linux kernel can run lots of containers.
• A VM is a pretend computer: each one runs its own operating system (Linux, Windows, BSD) on the same physical machine.
• Containers use less RAM: they share one kernel, so a machine can run thousands of small containers.
• Containers start faster: they're just processes, while a VM has to boot an operating system.
• Containers are harder to secure: a VM is isolated from other VMs by design; how isolated a container is depends on how it was configured.
• It's harder to know what a container can do: it looks like a computer but has exceptions a VM doesn't have.

Serverless

In serverless computing the cloud provider allocates machine resources dynamically; developers deploy code and the provider runs the infrastructure.

• Pros: cost-effective for sporadic or event-driven work, since you pay only for actual processing time; scales automatically with unpredictable traffic.
• Cons: cold starts, a delay when a function runs after being idle; less control over the infrastructure and runtime.
• When to use: event-driven applications, quick prototypes, and workloads with unpredictable demand such as APIs, data processing and IoT. See serverless.

The four compared

How each isolates workloads

• Namespaces give a container its own view of process IDs, network interfaces, mount points, hostnames and users, so it can't see other processes.
• cgroups limit and account for CPU, memory and I/O, so one container can't starve the others.
• Images are layered, read-only filesystems with the app and its dependencies, built once and run identically everywhere.

Containers vs VMs compared

Stronger isolation for containers

When untrusted code shares hosts (multi-tenant platforms, user-submitted code), plain containers aren't enough. Options include running each tenant's containers in separate VMs or node pools, sandboxed runtimes that intercept system calls in user space, and microVMs that start a minimal VM per container in a fraction of a second, which is how many serverless platforms isolate functions. Defence in depth also means running containers as non-root, dropping Linux capabilities, using read-only filesystems and restricting system calls.

Why containers changed deployment

• Immutable artifacts: the same image runs in CI, staging and production, removing "works on my machine" differences.
• Fast scaling and recovery: new instances start in seconds, which makes autoscaling and replacing unhealthy instances cheap.
• Bin-packing: an orchestrator such as Kubernetes packs many containers onto fewer machines, raising utilisation.
• Clear contracts: an image declares its ports, environment and resource requests, so platforms can run any team's service the same way.

Containers are not lightweight VMs: treat them as disposable processes. Keep state in databases or volumes, log to stdout, and expect any container to be killed and replaced at any time.