People throw around VPS, VM, and containers interchangeably. They shouldn’t. All three solve the same problem: packing more workloads onto fewer machines. They just do it at different abstraction levels.
VPS
A VPS is a marketing term, not a technology. You rent a slice of a machine (or a VM) from a provider. They are using virtualization or container tech under the hood, but you don’t see it.
Think of it as a productized VM. Providers oversell density, so you get many VPS per host. You get root access, but isolation is not guaranteed.
VM
Hardware-level virtualization. A hypervisor (KVM, Xen, VMware, Hyper-V) carves a single physical host into multiple VMs, each with its own OS kernel.
- Isolation: strong. Each VM runs as if it had its own machine.
- Overhead: high. Every VM boots a full kernel, needs system packages, and so on.
Perfect for multi-tenant isolation (finance, healthcare). Use one when you need strong security boundaries.
Containers
OS-level virtualization. Processes share the same kernel, but namespaces and cgroups isolate filesystem, networking, CPU, and memory.
- Isolation: weaker than VMs (shared kernel), but good enough for most apps.
- Overhead: minimal. No guest OS, containers start in milliseconds.
This is why Kubernetes won: containers gave cloud-scale density and portability without the VM bloat.
How we got here
- 2000s: VMs exploded. Enterprises loved the strong isolation, hated the bare-metal waste.
- 2010s: containers took over. Faster, lighter, cloud-native orchestration (K8s).
- 2020s: a mix of both. Security-sensitive workloads still run on VMs, but most app stacks run in containers on top of VMs (EKS/GKE/AKS).
There is also some middle space between VMs and containers. Things like Firecracker, which is what AWS Lambda uses behind the scenes.
The mental model
- VPS = the product you rent
- VM = virtual hardware
- Container = virtual process
Isolation ↑ as you move down. Density ↑ as you move up.