Compute options overview: VMs, containers, and serverless

Whatever you're building eventually needs actual CPU cycles to execute on, and cloud providers offer three fundamentally different shapes of compute to run it on. The right choice depends on the same question that ran through the previous lesson's service models: how much control do you need, versus how much operational effort are you willing to take on?

A virtual machine (AWS EC2, Google Compute Engine) is the closest cloud equivalent to a physical server — you get a full operating system, root/administrator access, and the ability to install and configure anything. You're responsible for patching the OS, managing dependencies, and scaling (manually, or via auto-scaling groups, covered later in this domain).

Best fit: workloads with specific OS-level requirements, legacy applications being lifted-and-shifted from on-prem, or situations needing fine-grained control over the runtime environment.

A container (covered in full depth in the dedicated Docker & Containers domain) packages an application with its dependencies into a portable, lightweight unit that runs consistently across environments — without the overhead of a full separate operating system per workload the way a VM has. An orchestrator (ECS, Kubernetes) manages running, scaling, and replacing containers automatically.

Best fit: applications that benefit from consistent packaging across dev/staging/production, workloads needing to scale many small, identical instances efficiently, and teams wanting more portability than a VM but more control than serverless.

Containers share the host machine's OS kernel rather than each running a full separate guest OS, which is exactly why they start faster and pack more densely onto the same hardware than an equivalent number of VMs would.

Serverless compute (AWS Lambda, covered in its own lesson later in this domain) removes the concept of a persistent server entirely — you write a function, the platform runs it only when triggered by an event, and it scales automatically, including down to zero when idle (so there's genuinely nothing running, and nothing billing, between invocations).

Best fit: event-driven, bursty workloads (processing an uploaded file, handling occasional webhook traffic, scheduled jobs) where paying for idle capacity between events would be wasteful.

A realistic production system commonly uses more than one of these simultaneously — a core API running on containers for steady, predictable traffic; a handful of background jobs running on serverless functions triggered by queue messages or scheduled events; maybe one legacy component still running on a VM because migrating it isn't worth the effort yet. The skill this domain is building toward isn't "always use containers" or "always use serverless" — it's recognizing which shape actually fits a given workload's traffic pattern, operational requirements, and team's appetite for infrastructure management, and being comfortable running a mix.