How To Always Know Where A Process Runs
All the systems we work on as software makers can be understood by separating the three independent questions that are often confused and mixed together.
First: where does it run? That’s either on‑premise (a physical data center, full of servers, that your company owns) or cloud (hardware owned by a cloud provider, like AWS, that your company leases). This determines the first layer — who physically owns the machines, who pays for them, which country they’re in, and who is responsible when infrastructure fails.
Second: what level of hardware abstraction exists? A workload runs either on bare metal (directly on a physical server) or inside a virtual machine (via a hypervisor). Virtualization affects performance isolation and operational flexibility, but it doesn’t change the core reality: software is still just a process running on an operating system.
Third: how is the process launched and isolated? Software can run directly on the OS or be containerized using tools like Docker or Kubernetes. Containers do not replace machines or virtual machines; they only change how processes are packaged, started, and managed. Nearly every system can be described using these three axes — everything else is abstraction layered on top.
Classify a system in 10 seconds
Pick one option per axis. You’ll get a crisp sentence you can use in design reviews, onboarding, or incident discussions.
- A cloud provider owns the hardware; your company leases it.
- There’s a hypervisor: your OS is running on virtual hardware.
- Your process is packaged + started by a container runtime (often via Kubernetes).