Lesson 1: The Azure Compute Map on One Page

Why start with a map

Azure has more than a dozen ways to run code, and their names keep changing. Before you choose one, you need a mental map: which services exist, what kind of hosting each one is, and who looks after what. Think of it as a building directory. You find the right floor first, then the right room.

In this course we use four hosting models. Microsoft's own guide uses three categories (IaaS, PaaS and FaaS). We add a fourth, specialised hosting, for services built for one narrow job.

The map

Gotcha: autoscaling is not just a PaaS feature. Microsoft's guide points out that VMs scale automatically through scale sets. Check each service, not the category.

CycleCloud is unusual: it is an orchestration application you install on a VM. It then builds HPC clusters for schedulers such as Slurm. You run it yourself.

See the map in your own subscription

Every service is backed by a resource provider namespace. Checking which ones are registered tells you what your subscription is already set up to use:

# List the compute-related resource providers and whether they are registered
az provider list \
  --query "[?contains(['Microsoft.Compute','Microsoft.Batch','Microsoft.ContainerService','Microsoft.App','Microsoft.ContainerInstance','Microsoft.Web','Microsoft.RedHatOpenShift','Microsoft.AVS','Microsoft.AppPlatform'], namespace)].{ns:namespace, state:registrationState}" \
  -o table

Ns                          State
--------------------------  -------------
Microsoft.Compute           Registered     # VMs, Spot, scale sets, Dedicated Host
Microsoft.Web               Registered     # App Service and Functions share it
Microsoft.ContainerService  Registered     # AKS
Microsoft.App               NotRegistered  # Container Apps
Microsoft.AppPlatform       NotRegistered  # Spring Apps (formerly Spring Cloud)
...

The namespaces carry history. Microsoft.Web comes from the Azure Websites days, and Microsoft.AppPlatform from Spring Cloud. Old names live on in APIs long after the marketing name changes.

Walking Microsoft's decision tree

Microsoft publishes a flowchart in the Azure Architecture Center: Choose an Azure compute service. Here it is in simplified form:

1. Migrate or build new?
2. Migrate: Is the app already cloud-optimised? Then App Service. If not, can it be lifted and shifted? A VMware estate goes to Azure VMware Solution; anything else goes to Virtual Machines.
3. Build new: Do you need full control? Then VMs. HPC? Then Batch. Event-driven? Then Functions. Managed web hosting? Then App Service. If it's containers, the answers about orchestration lead to Container Instances, Container Apps, AKS or Azure Red Hat OpenShift.

One line in the guide matters a lot. Container Apps runs on Kubernetes but doesn't give you direct access to the Kubernetes APIs. If you need the API or the control plane, use AKS.

Worked example

A bank runs a nightly Monte Carlo risk job: an existing Linux binary and 2,000 independent simulations, with a deadline of 06:00.

• Tree: Migrate, not cloud-optimised, so lift and shift, which leads to Virtual Machines.
• Judgement: the work is embarrassingly parallel and runs in batches. A pool that grows for the run and then scales to zero fits much better. That points you to Batch, or to CycleCloud if the team already uses Slurm. The tree only reaches Batch on the build new branch.

Where the tree stops

• Microsoft calls its output "your starting point". You still check limits, cost, regions and SLAs.
• It covers general-purpose compute. CycleCloud, Dedicated Hosts, Service Fabric, SAP and Oracle appear in a separate "specialty workloads" table.
• It doesn't cover VM series, Spot pricing, licensing or data gravity.
• A system with distinct parts may need two or more services. Run each part through the tree separately.

Current and former names

Best practice: when an old design document or quote names ACS or Spring Cloud, translate it to the current service before you compare prices. Otherwise you may be comparing against something you can no longer buy.

Key takeaways

• Four hosting models: IaaS, managed containers, PaaS and serverless, and specialised. The further you move from IaaS, the less of the OS, runtime and scaling you operate.
• Microsoft's tree starts with migrate or build new, and its answer is only a starting point.
• Use your own judgement for HPC, parallel batch work, specialty workloads and systems with several components.
• Container Apps hides the Kubernetes API. Choose AKS when you need it.
• Learn the old names: ACS became AKS, Spring Cloud became Spring Apps (retiring 2028), and Cloud Services (classic) is gone.