5.1.1. Design a Compute Solution
💡 First Principle: Selecting the optimal compute service requires a thorough evaluation of workload characteristics against the operational models, scalability patterns, and cost structures of available IaaS, PaaS, container, and serverless options.
Choosing an Azure compute service:
⚠️ The branch that decides most exam questions is the last one, and it is rarely technical. AKS and Container Apps will both run the container — what separates them is whether the organization can operate a Kubernetes cluster. When a scenario mentions a small team, no Kubernetes experience, or a decision not to take on cluster operations, that sentence is the answer key, not scene-setting.
Specialized compute the flowchart leaves out:
| Service | Choose it when | It is the wrong answer when |
|---|---|---|
| Azure Batch | Many independent tasks (rendering, simulation, genomics) run in parallel across a pool of VMs that Batch provisions, scales and releases when the job ends; Spot nodes cut the cost of interruptible tasks | The work is a long-running service or a short event handler |
| Azure Container Apps | Containerized microservices need built-in Dapr, KEDA scale rules (HTTP, queue depth, events) and scale to zero, without anyone operating Kubernetes | The design needs the Kubernetes API itself — custom admission controllers, CNI network policies, operators — which only AKS exposes |
| Azure Container Instances | A single container or container group started on demand, or burst capacity for AKS through virtual nodes | The workload needs orchestration — service discovery, rolling updates and autoscale are not built in |
| Azure Virtual Desktop | Users need full Windows desktops or apps hosted in Azure: Windows 11 Enterprise multi-session hosts, FSLogix profile containers, Microsoft Entra sign-in with Conditional Access | Only a web application needs publishing — that is App Service |
| Azure Machine Learning | Data scientists train and track models: managed CPU and GPU compute, notebooks, experiment tracking and a model registry in one workspace | Plain GPU compute is all that is needed and nobody will track experiments |
Scenario: You are designing the compute layer for a new enterprise application. This involves determining the best hosting solution for a legacy component requiring full OS control, a new web API that needs auto-scaling, and event-driven background tasks.
A compute solution refers to the choice of Azure services and configurations used to host and execute your application code.
This task delves into the practical application of Azure's compute services. You'll explore how to:
- Design for Azure Virtual Machines (VMs): Implementing IaaS for full control over the operating system.
- Design for Azure App Service: Providing a fully managed PaaS for web apps and APIs.
- Design for Azure Kubernetes Service (AKS): Managing containerized applications at scale.
- Design for Azure Functions: Implementing serverless, event-driven compute.
Mastering these concepts is crucial for the AZ-305 exam, as it assesses your ability to analyze, evaluate, and create comprehensive compute designs.
⚠️ Common Pitfall: Defaulting to a familiar compute service (like VMs) without evaluating if a more modern, managed, or serverless option would be a better fit, potentially leading to higher costs and operational burden.
Key Trade-Offs:
- Control vs. Cost/Simplicity: More control (IaaS) generally means more management responsibility and potentially higher TCO. Less control (Serverless) means less management and often lower costs for variable workloads.
Reflection Question: How do the characteristics of your application (e.g., stateless vs. stateful, event-driven, containerized, custom OS needs) fundamentally influence your choice of Azure compute service for optimal performance, scalability, and cost-effectiveness?
