Compute & Container Platforms

Compute & Container Platforms are the engines a workload actually runs on — virtual machines, containers/Kubernetes, or serverless functions — each trading off control, portability, and operational effort differently.

At a glance

• What it is: the choice between VMs (full OS control), containers/Kubernetes (packaged, portable, orchestrated), and serverless functions (event-triggered, no server management).
• Why it matters: this choice drives how much operational code — patching, scaling logic, orchestration — a team writes and maintains versus what the platform handles.
• For developers: don’t default to “spin up a VM” out of habit — check whether the workload’s actual shape (long-running vs. event-driven, stateful vs. stateless) points to a container or serverless option that removes entire categories of ops work.
• When to use it: whenever selecting how a specific service/component will run, after the higher-level Cloud Service & Deployment Model decision.
• When not to use it: doesn’t apply to SaaS products where there’s no compute to choose.
• Prerequisites: Cloud Service & Deployment Models.

Mental model

graph LR
    VM["Virtual machines: full OS control, you patch/scale"] --> Containers["Containers/Kubernetes: packaged, orchestrated, portable"] --> Serverless["Serverless: event-triggered, no server management"]

Step-by-step walkthrough

1. Characterize the workload: long-running vs. short/event-driven, stateful vs. stateless, predictable vs. bursty traffic.
2. Rule out VMs unless there’s a specific need for OS-level control or software that doesn’t containerize well.
3. Choose containers/Kubernetes for workloads needing fine-grained scaling, portability across environments, or complex multi-service orchestration.
4. Choose serverless for event-driven, bursty, or intermittent workloads where paying only for actual execution time matters.
5. Confirm the chosen platform fits the team’s existing operational skillset — Kubernetes in particular has a real ongoing operational cost.

Worked example

Northwind’s checkout platform must launch in a new region on a tight deadline, and the team is deciding how the service should run there.

• Input: an existing checkout stack with a stateful order-processing component and several bursty, read-heavy endpoints (like price lookups).
• Process: the team rules out VM lift-and-shift, since it would mean owning patching and scaling with no real benefit; evaluates AKS versus Azure Functions; and, because the workload has two different shapes, splits it — containers (AKS) for the stateful order-processing component, and serverless (Functions) for the lightweight, bursty read endpoints.
• Output: a hybrid, PaaS-first setup — AKS for order processing, Functions for bursty reads — with no new VMs to patch and each component running on the platform best suited to its actual traffic shape.

[Function("GetPrice")]
public async Task<HttpResponseData> GetPrice(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = "price/{sku}")] HttpRequestData req,
    string sku)
{
    var price = await _priceCache.GetOrAddAsync(sku, () => _priceService.LookupAsync(sku));
    var response = req.CreateResponse(HttpStatusCode.OK);
    await response.WriteAsJsonAsync(price);
    return response;
}

This bursty read endpoint runs as an Azure Functions app on a consumption plan (scales to zero between spikes), while the stateful order-processing component runs as a deployment on AKS.

Common use cases

Use case	When to use	Notes
Long-running, stateful service with complex orchestration needs	Containers / Kubernetes	Justifies the operational investment
Bursty, event-driven, intermittent workload	Serverless / FaaS	Pay only for actual execution time
Software requiring OS-level access or unsupported for containers	Virtual machines	Accept the added patching/ops burden as a deliberate tradeoff

Advanced details

• Kubernetes gives fine-grained control and portability but carries genuine ongoing operational cost (upgrades, node pool management) — adopt it because you need its specific capabilities, not because “everyone does.”
• Serverless cold starts can matter for latency-sensitive synchronous calls — profile before assuming serverless is “free” performance-wise.
• Container images should be built from minimal, patched base images and scanned in CI — the shared responsibility model still puts image content squarely on the workload team.

Quick reference

Term	Meaning
VM	A full OS-level control machine; you manage patching and scaling
Container	A packaged, portable unit of an app and its dependencies
Kubernetes	An orchestration platform for scheduling, scaling, and healing containers
Serverless / FaaS	Event-triggered compute with no server management, billed per execution
Cold start	Latency incurred when serverless infrastructure spins up an idle function

Troubleshooting

Symptom	Likely cause	Fix
Team spends significant time patching/maintaining VM OS images	Workload runs on VMs where containers/serverless would suffice	Containerize or move to serverless if the workload shape allows it
Serverless function has unpredictable latency spikes	Cold starts on infrequently invoked functions	Use provisioned concurrency/minimum instances, or move latency-critical paths to containers
Kubernetes cluster requires a dedicated ops person just to keep running	Adopted for portability/fashion without matching operational investment	Reconsider whether a managed PaaS or serverless option meets the actual requirement

Check your understanding

• What workload characteristics point toward serverless over containers, and vice versa?
• Why is “we already know Kubernetes” not, by itself, a sufficient reason to run every workload on it?

Related pages

Part of Introduction to Cloud & Infrastructure Architecture. See also Cloud Service & Deployment Models, Capacity & Scalability Planning, Infrastructure as Code & Provisioning, and the Glossary.