1. Compute Decision Tree
Start every compute decision with workload characteristics, not brand loyalty:
2. Decision Axes
Six dimensions that influence every compute choice:
| Axis | Key Question | Impact |
|---|---|---|
| Team Skills | Kubernetes expertise? | No → avoid AKS overhead |
| Scaling | Predictable or spiky? | Spiky → Functions / Container Apps |
| State | Stateful or stateless? | Stateful → VM / StatefulSets in AKS |
| Latency | Sub-ms or tolerant? | Ultra-low → dedicated VMs / proximity groups |
| Networking | VNet integration, private endpoints? | Complex → AKS / App Service Premium |
| Cost | Budget-constrained? | Pay-per-use → Functions Consumption |
3. Service Comparison Matrix
| Service | Scaling | Min Mgmt | Containers | Cost Model | Best For |
|---|---|---|---|---|---|
| VMs / VMSS | Manual / autoscale rules | High | Manual | Per-hour | Legacy, full control |
| App Service | Built-in autoscale | Low | Yes (Linux) | Per-plan | Web apps, APIs |
| Functions | Event-driven auto | Very low | Optional | Per-execution | Event processing, glue |
| ACI | None (per-group) | Very low | Required | Per-second | Batch, sidecar, burst |
| Container Apps | KEDA-based, scale-to-zero | Low | Required | Per-second + requests | Microservices, APIs |
| AKS | Cluster + pod autoscaler | Medium-High | Required | Per-node | Complex microservices |
4. Workload Archetypes
- Simple Web App / API → App Service — managed TLS, deployment slots, autoscale included
- Event-Driven Processing → Azure Functions — queue triggers, timer jobs, pay-per-execution
- Microservices (small team) → Container Apps — Dapr, KEDA, zero Kubernetes YAML
- Microservices (large team / complex) → AKS — full control, service mesh, custom CNI
- Batch / Burst Processing → ACI + Spot VMs — spin up, process, tear down
- Legacy / Vendor Software → VMs / VMSS — no code changes, lift-and-shift
5. Progressive Modernization Path
Most organizations evolve through compute tiers incrementally:
6. Real-World: Contoso's Five Workloads
Scenario: Contoso Ltd migrates five workloads to Azure. Each has different characteristics:
| Workload | Characteristics | Chosen Service | Rationale |
|---|---|---|---|
| Customer Portal | .NET web app, predictable traffic | App Service P1v3 | Managed, deployment slots, easy CI/CD |
| Order Processor | Queue-triggered, bursty | Functions (Consumption) | Pay-per-message, auto-scales to zero |
| Recommendation Engine | Python ML, GPU needed | VMSS (NC-series) | GPU drivers, full OS control |
| Shipping Microservices | 4 services, small team | Container Apps | Dapr service invocation, no K8s ops needed |
| Nightly Report Gen | 2-hour batch, runs at midnight | ACI + Spot | Per-second billing, no idle cost |
Result: 40% cost reduction vs. putting everything on VMs; each team uses the right abstraction level.
7. Exam Tip
- Don't pick AKS when Container Apps satisfies the requirement
- Don't pick VMs when App Service works — unless OS-level access is explicitly needed
- Functions Consumption has a 5-min default timeout (10 max) — long-running = Premium or Dedicated
- "Scale to zero" + containers = Container Apps, not AKS
8. Knowledge Check
Q1: A startup has a containerized API with unpredictable traffic and no Kubernetes expertise. Which service?
Q2: A legacy Windows application requires specific registry edits and a custom device driver. Which compute?
Q3: An event-driven workload processes Service Bus messages in under 30 seconds per message with highly variable volume. Minimize cost.
Q4: A team of 50 engineers operates 30 microservices needing custom CNI, service mesh, and pod-level network policies. Which compute?
Q5: What is the recommended modernization step AFTER lifting a monolithic app to a VM?