Compute#
A consumption-side overview of compute options. Where the deeper runtime pages (Runtimes) describe how each layer works, this page is the selection guide, which compute option fits which workload. The choice also fixes where the operator’s workloads run, and how a target’s compute drives an attacker’s persistence.
flowchart TB
Q{Workload type?}
Q -->|"Long-lived service<br/>steady traffic"| Container[Containers on Kubernetes / Nomad / managed]
Q -->|"Spiky / event-driven<br/>scale to zero"| FaaS[Serverless functions]
Q -->|"Long-lived but<br/>simple deployment"| PaaS[PaaS / managed container service]
Q -->|"Stateful / heritage"| VM[Virtual Machines]
Q -->|"Edge / low-latency<br/>near user"| Edge[Edge runtimes]
Q -->|"Strong tenant isolation"| microVM[microVMs / Kata]
Q -->|"Bare hardware needed"| Metal[Bare metal / dedicated]
Q -->|"High-throughput batch"| Batch[Batch / job systems]
The Compute Spectrum#
Option |
Granularity |
Startup time |
Operational model |
|---|---|---|---|
Bare metal |
Server |
Minutes |
You manage everything |
Virtual Machine |
VM |
10-30 s cold |
Cloud manages hardware |
Container |
Process |
<1 s |
Orchestrator manages scheduling |
microVM |
VM-ish |
~125 ms |
Platform manages lifecycle |
Function (FaaS) |
Function call |
100 ms - 3 s |
Provider manages compute |
Edge runtime (V8 / Wasm) |
Isolate |
<10 ms |
Provider manages globally |
Each row trades control for operational simplicity. Bare metal gives you everything; FaaS gives you almost nothing to operate. The same row decides an attacker’s persistence options, a long-lived VM persists like a host, a function leaves almost nowhere to hide.
Choosing#
Heuristics for the typical product team. Match the workload type to the compute that fits it; run the same heuristics backward and they explain why a target landed where it did.
Workload |
Pick |
|---|---|
Default |
Containers on managed Kubernetes or a managed container service |
Spiky or event-driven |
FaaS (Lambda, Cloud Functions, Azure Functions) |
Edge or auth middleware |
Edge runtimes (Cloudflare Workers, Vercel Edge, Deno Deploy) |
Stateful databases or brokers |
Managed services first, then StatefulSets, then VMs |
Strong tenant isolation |
microVMs (Firecracker, Kata) |
Specialized hardware |
Bare metal or VMs with GPU or FPGA passthrough |
The cheapest answer depends on utilization. Below roughly 20-30% utilization, serverless wins; above that, always-on containers usually do.
Capacity and Scaling#
The four levers that move capacity. Most production capacity stories blend all four with different urgency.
Lever |
What it does |
|---|---|
Vertical |
Bigger machines, cheap for moderate growth, capped by the largest instance |
Horizontal |
More machines, needs a load balancer and a stateless or shardable workload |
Auto-scaling |
React to CPU, memory, or queue depth, and verify it actually fires under load |
Right-sizing |
Most workloads are over-provisioned 2-4x, so profile then size |
Cost Model (Roughly)#
Option |
Cost characteristic |
|---|---|
Bare metal |
capex + opex; cheapest at high steady utilization |
VMs |
per-hour while running; per-second on cloud |
Reserved / Savings Plans |
30-70% off list, with 1-3 year commits |
Spot / preemptible |
60-90% off list; can be reclaimed |
Containers |
priced by node fleet; orchestrator overhead small |
Serverless |
per-request × duration × memory |
Edge |
per-request; pricing dominated by request count |
For predictable steady workloads, commit-based discounts are usually the biggest win. For spiky workloads, serverless. For experiments, spot.
Where the Other Components Connect#
Compute is rarely deployed alone:
Networking, load balancers in front of compute; service mesh inside the cluster (Networking).
Storage, compute is stateless; state lives in databases, caches, queues, object storage (Storage).
Security, workload identity, IAM, secrets all bind to compute instances (Security).
Observability, compute emits metrics / logs / traces (Observability).