CH20-04: Compute and Container Services
Goal
Compute services run code. The hard part is not asking whether a service can run the workload. Many services can. The architecture question is which runtime gives the right balance of control, scaling, deployment model, team skill, reliability, and operations.
The durable idea is:
Compute selection is responsibility matching: choose the runtime whose control, scaling, and operating model fit the workload.
The Short Version
Start with the execution model:
| Workload Need | Common Azure Direction |
|---|---|
| Managed web app or API | Azure App Service. |
| Event-triggered unit of work | Azure Functions. |
| Managed containers without direct Kubernetes operations | Azure Container Apps. |
| Kubernetes APIs, ecosystem, and platform standardization | Azure Kubernetes Service. |
| Full OS control or legacy runtime | Azure Virtual Machines. |
| Fleet of similar VMs | Virtual Machine Scale Sets. |
| Large parallel jobs | Azure Batch. |
| Static frontend with integrated deployment | Azure Static Web Apps. |
Service Reference
| Service | Purpose | Use When | Avoid When | Common Prompt |
|---|---|---|---|---|
| Azure App Service | Managed hosting for web apps, APIs, and background web workloads. | You want managed platform hosting without managing VMs or Kubernetes. | You need deep OS control, custom cluster behavior, or specialized runtime dependencies. | Can managed web hosting run this workload? |
| Azure Functions | Event-driven serverless compute. | Work is triggered by events, timers, queues, HTTP, or automation and can be packaged as units of work. | The workload has long-running, stateful, tightly coupled, or platform-heavy requirements that do not fit the execution model. | Is this event-triggered work? |
| Azure Container Apps | Managed container hosting with serverless-style scaling and microservice support. | You want to run containers without owning a Kubernetes control plane. | You need full Kubernetes APIs, custom operators, deep cluster control, or a mature Kubernetes platform standard. | Do containers need Kubernetes ownership? |
| Azure Kubernetes Service | Managed Kubernetes control plane for container platforms. | The organization needs Kubernetes APIs, ecosystem tools, platform standardization, or complex container orchestration. | The team is not prepared to own cluster operations, security, networking, upgrades, and platform reliability. | Is Kubernetes justified by platform needs? |
| Azure Virtual Machines | Infrastructure as a service compute with OS-level control. | You need legacy compatibility, custom OS configuration, specialized software, or lift-and-shift migration. | Managed hosting or containers would meet the need with less operational burden. | Do we need OS control? |
| Virtual Machine Scale Sets | Managed group of identical VMs with scaling. | You need scalable VM fleets, custom images, or VM-based worker pools. | A managed app, container, or serverless service can absorb the work. | Do we need a scalable VM fleet? |
| Azure Batch | Managed scheduling for large-scale parallel and batch computing jobs. | You need pools of compute for parallel jobs, rendering, simulations, or batch processing. | You are hosting normal web APIs or always-on services. | Is this large parallel batch work? |
| Azure Static Web Apps | Hosting for static frontends and integrated serverless APIs. | You need static site hosting for frontend apps with simple deployment and global distribution. | The app needs complex server-side runtime control. | Is this mostly a static frontend? |
Commonly Confused Services
| Comparison | Short Answer |
|---|---|
| App Service vs VMs | App Service reduces platform operations for web apps; VMs give OS control with more responsibility. |
| Functions vs App Service | Functions fit event-triggered units of work; App Service fits web apps and APIs with a more traditional hosting model. |
| Container Apps vs AKS | Container Apps runs containers with less platform ownership; AKS fits when Kubernetes itself is the platform requirement. |
| AKS vs VMs | AKS manages container orchestration; VMs give direct server control. Both still need operations. |
| Batch vs Functions | Batch fits large parallel jobs; Functions fits event-triggered units of work. |
Architecture Patterns
Compute services often appear in patterns such as:
Managed web application with App Service, Application Gateway or Front Door, Azure SQL, Key Vault, and Azure Monitor.
Event-driven processing with Functions and Service Bus or Event Grid.
Microservices on Container Apps when the team wants containers without owning Kubernetes.
Enterprise Kubernetes platform on AKS with platform engineering ownership.
Lift-and-shift modernization with VMs first, then gradual migration to managed hosting or containers.
Parallel job processing with Azure Batch and storage-backed inputs and outputs.
Cloud Comparison
AWS and GCP users can translate roughly by responsibility: managed app hosting, functions, containers, Kubernetes, VMs, and batch compute exist in all major clouds. But direct mapping is incomplete. The real choice is about the operating model your team accepts.
For example, "the app uses containers" does not automatically mean AKS. Containers can run on Container Apps, App Service, AKS, or other hosting choices depending on control, scale, networking, deployment, and platform ownership.
Common Mistakes
Choosing AKS because the application uses containers.
Choosing serverless without considering execution duration, cold starts, dependencies, and observability.
Defaulting to VMs when managed hosting would reduce operations.
Ignoring deployment, scaling, incident response, and cost model.
Splitting an application into many functions before understanding ownership and workflow boundaries.
Underestimating platform work for Kubernetes networking, identity, upgrades, policies, and observability.
If Someone Asks You
How do I choose Azure compute services quickly?
A good answer is:
Choose compute by execution model and responsibility. App Service is a strong starting point for managed web apps and APIs. Functions fits event-triggered units of work. Container Apps runs containers with less Kubernetes ownership. AKS is for teams that need Kubernetes APIs and can operate the platform. VMs fit OS control and legacy needs. Batch fits large parallel jobs. Static Web Apps fits static frontends.
What You Should Remember
Choose compute by execution model, control needs, scaling behavior, team skill, and operations.
Questions to Check Understanding
When is App Service a better starting point than VMs?
Why does AKS require platform ownership?
When might Container Apps be enough for microservices?