Compute Models
Virtual machines, containers, serverless functions and dedicated hardware — chosen by workload shape rather than by modernity.
Definition
The unit of compute you deploy determines your cost curve, your startup latency, your isolation boundary and your operational burden. The four common models sit on a spectrum from most control to least.
| Model | You manage | Good for | Bad for |
|---|---|---|---|
| Bare metal / dedicated | Everything | Predictable heavy load; hardware-specific work | Elasticity; small workloads |
| Virtual machines | OS and up | Long-running services; legacy; specific kernel needs | Fast scaling; fine-grained packing |
| Containers | Image and up | Most services; polyglot estates; density | Very spiky sub-minute bursts |
| Serverless functions | Code only | Bursty, event-driven, low-duty-cycle work | Sustained high load; long tasks; latency floors |
How to choose
The decisive questions are duty cycle and startup latency tolerance.
A workload running continuously at meaningful utilisation is cheapest on reserved capacity, because serverless charges a premium for the elasticity you are not using. A workload that runs for 200 ms every few minutes is absurdly expensive on a permanently provisioned instance and nearly free on functions.
The crossover is a real calculation, not a philosophy, and it is worth doing: many teams adopt serverless for a workload whose steady load makes it several times more expensive than a small always-on instance.
Industry example
Real-time media is the case that resists the modern default. Zoom's media path needs sustained throughput, predictable low latency, direct control over networking, and no cold starts — a combination that points at dedicated capacity in owned or co-located infrastructure rather than at elastic cloud compute.
Two lessons come out of that. First, the workload with the tightest latency floor usually dictates the compute model for that path, and only that path — the signalling, scheduling, billing and web surfaces around it have completely different profiles and can live anywhere. Second, when demand can step by an order of magnitude in weeks, physical capacity lead time becomes the binding constraint, which is an argument for hybrid: owned capacity for the predictable base, cloud for the surge.
Failure scenarios
- Serverless for a sustained workload, paying an elasticity premium continuously.
- Cold starts in a latency-sensitive path, discovered in production at p99.
- Containers without resource limits, so one noisy workload starves its neighbours on the node.
- Lift-and-shift VMs into the cloud at the same sizes as on-premises, which is how migrations produce a bill three times the data-centre cost.
- A function timeout shorter than the work, so long tasks fail silently at the limit.
Trade-offs
Moving down the list buys operational relief and elasticity, and costs control, predictability and per-unit cost at high utilisation. Most real systems are mixed, and that is correct: functions for event handling, containers for services, and dedicated capacity for the one workload with a hard constraint.
Interview question
"When is serverless more expensive than a reserved instance, and how would you calculate the crossover?"