Azure / Basic: scope, identity, location, and resources / Lesson 5

Compute choices and workload responsibility

Choose a hosting model from application requirements rather than service popularity. Compare virtual machines, managed web hosting, functions, and containers while keeping capacity assumptions explicit.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Map operating-system and application needs to candidates.
Separate autoscaling from resilience and state correctness.
Calculate a synthetic capacity margin without pricing claims.

Start with what the workload must control

Azure offers several compute abstractions, including Virtual Machines, App Service, Functions, Container Apps, and Azure Kubernetes Service. They trade control, operational responsibility, execution model, and integration features differently. A workload needing a particular guest operating-system agent may fit a VM candidate; a conventional HTTP application may fit managed web hosting; an event-triggered task may fit Functions. A container image alone does not require Kubernetes. Treat these as candidates to evaluate, not universal recommendations. Check supported runtimes, network integration, deployment model, scaling limits, observability, and regional availability for the specific option.

Managed hosting still leaves application work

With VMs, the workload team commonly owns more guest configuration, patch coordination, runtime, and capacity operations than with a managed application platform. Managed options can reduce that work without taking responsibility for every library, application bug, data dependency, identity grant, or recovery objective. The planning model below records why three workloads have different candidates. It is not a deployment configuration or a promise that each option supports an unspecified operating system or extension. Document the rejected alternatives too, because later requirements can invalidate the original choice and make migration costs significant.

json A workload-to-candidate decision model

{
  "model": "compute-candidates-only",
  "workloads": [
    {
      "need": "guest-os-agent",
      "candidate": "Azure Virtual Machines"
    },
    {
      "need": "managed-http-application",
      "candidate": "Azure App Service"
    },
    {
      "need": "containerized-http-without-cluster-ownership",
      "candidate": "Azure Container Apps"
    }
  ]
}

Expected output

evaluate each candidate against runtime, network, scale, and recovery requirements

Candidate selection is not validation of a service configuration or a claim of lower cost. No cloud resource is created.

Use measured workload units, not a magic instance count

A capacity model needs a demand definition, per-instance evidence, headroom, and the failure it must tolerate. The offline example uses invented work units: demand 430 per interval, measured-for-the-model capacity 100 per instance, and a 25 percent planning margin. Six instances meet that arithmetic target, while seven preserve it after losing one equal instance. These values are not Azure throughput figures, VM recommendations, or a pricing estimate. A real plan must measure startup delay, dependency limits, request mix, and degraded operation before accepting a scale rule. Capacity must remain useful after the stated failure.

python Offline synthetic headroom and failure allowance

from math import ceil
demand = 430
capacity_per_instance = 100
required = ceil(demand * 125 / (100 * capacity_per_instance))
with_one_instance_failure = required + 1
print(required, with_one_instance_failure)

Expected output

6 7

The model calculates counts only. It does not benchmark Azure compute, test autoscale, or predict a bill.

Scaling must preserve state and lifecycle semantics

Horizontal scale adds or removes instances; vertical scale changes a resource’s size or capability. Neither automatically fixes a single shared database, local-session dependency, or non-idempotent background task. Keep durable state outside disposable instance-local storage where the workload requires persistence, and define connection draining and in-flight work behavior before scale-in. Autoscale responds to configured signals and policies, not directly to every business objective. A CPU rule can miss queue delay or an external service bottleneck. Use bounded metrics and appropriate cooldown or stabilization behavior, then verify the full user outcome under representative conditions.

Availability depends on the whole compute path

An instance running successfully does not prove the application is ready to serve its task. Health signals, load distribution, zone placement, data access, secrets, runtime support, and deployment compatibility all matter. Distinguish liveness from readiness and from successful business completion. A restart can clear a symptom while losing work or repeating an effect, so record evidence before proposing an operational action. This course performs no VM operations, image builds, cluster actions, service calls, or load tests. It teaches a reviewable selection and capacity argument whose assumptions must be checked before any later authorized deployment.

Common errors and fixes

A container image automatically leads to AKS

Why it happens: Packaging format is confused with orchestration requirements.
How to fix it: Compare simpler managed container candidates against actual needs.
Prevent it next time: Record the capabilities that justify cluster ownership.

Autoscale is assumed to repair all availability problems

Why it happens: Instance count replaces dependency and state reasoning.
How to fix it: Inspect the complete request and background-work path.
Prevent it next time: Test the intended degraded state and durable effects.

Synthetic capacity numbers are published as Azure benchmarks

Why it happens: Model assumptions are mistaken for measured platform results.
How to fix it: Label invented units and collect real authorized workload evidence separately.
Prevent it next time: Keep conditions and uncertainty beside every capacity claim.

Check your understanding

1. Why might a web API not need Kubernetes even when it ships as a container?

Show worked solution

A managed container or web platform may meet its HTTP, scaling, networking, and deployment requirements with less cluster responsibility. Compare actual constraints before choosing. If cluster-level control is essential, document that requirement and the operational ownership it introduces rather than treating container packaging as sufficient justification.

2. Six instances meet a synthetic margin target. Why does one-instance failure require a different plan?