First, what is compute?
Campux needs a vehicle for its application. Owning a car means choosing it, servicing it and dealing with a breakdown. Hiring a managed service leaves fewer mechanical chores, but also fewer choices about the engine. A fleet adds another question: how many vehicles do we need today? That is a useful starting picture for VMs, App Service and scale sets. Now replace the analogy with real requirements: operating-system control, supported runtime, workload shape, recovery and the bill.
A virtual machine (VM) gives you an operating system to manage. A VM scale set helps operate several similar VMs together. App Service hosts a web app or API without your team patching the underlying operating system. Azure Functions runs code in response to events, with behavior and billing that depend on its hosting plan. App Service Environment is a specialized, isolated App Service deployment; it is not the starting point for a small website.
The trade-off is control against operational work. A VM grants more OS control but asks you to patch and operate it. A managed service handles more of that work, while imposing its own limits. We will choose by requirements, not by which product sounds most advanced.
- Serverless
- You do not administer the underlying server. Azure still runs servers, and billing depends on the plan: a scale-to-zero plan can charge for execution while other plans keep capacity ready.
For each workload, ask: Is it a continuous web app or an event? How long does one run last? Does it require OS access? What network access, scaling, availability, and cost limits apply? These answers narrow the options.
Choose by appetite for chores, not fashion.
The track — six parts, App Service to bare metal
This page gives you the map. Six short follow-on parts examine the services in detail: the App Service plan and app, the specialized App Service Environment, VMs, scale sets, and a final decision exercise. You can start with the comparison here, then open the part that matches the workload you are considering.
- 11a · App Service Plans
- The plan is the machinery and the bill; apps ride on top. Tiers from Free to Isolated, scaling up versus scaling out, and the cost model — including the trap of a second plan you did not need.
- 11b · App Service
- Web apps and APIs with no operating system to patch: deployment slots and the swap, custom domains and free managed TLS, and the app settings and connection strings that carry your configuration and secrets.
- 11c · App Service Environment
- When shared hardware will not do: a single-tenant deployment of App Service into your own virtual network. What ASE v3 buys, what its Isolated v2 plans cost, and the cheaper answer that usually wins.
- 11d · Virtual Machines
- The owned car in full: series and sizing, images, availability sets versus zones, managed disks that outlive the machine, and extensions — the whole IaaS chore list, and how to carry it deliberately.
- 11e · VM Scale Sets
- Elasticity in raw compute: autoscale on a metric or a schedule, the Flexible and Uniform orchestration modes, and rolling upgrades that replace instances without dropping the fleet to zero.
- 11f · The Compute Decision Framework
- The whole spectrum as one decision: App Service versus Container Apps versus AKS versus Functions versus VMs, and the honest questions that place a workload on the lowest-chore rung it can tolerate.
The one table the whole class is built to fill in
Before the parts teach each rung in detail, hold the shape whole. Put the spectrum in one table and the decision stops being about which technology is most impressive and starts being about how many chores each workload justifies.
| Option | You still manage | Azure manages | Scales by |
|---|---|---|---|
| Virtual machine | Guest OS, patches, runtime, app | Physical host and virtualization | Resize or automate |
| VM scale set | OS image or guest upkeep, app | Instance orchestration | Configured metric or schedule |
| App Service | App code, dependencies, config, scale settings | Underlying OS and hosting platform | Manual or supported automatic method |
| Functions | Code, dependencies, triggers, data | Underlying host | Varies by hosting plan |
Read the table as a responsibility checklist, not a ranking of quality. Azure manages more infrastructure as you move toward managed services, but you always remain responsible for your code, configuration, identities, and data. For a web app, test App Service first. For an event, test the appropriate Functions hosting plan. For a program requiring guest OS control, consider a VM; if you need many similar VMs, consider a scale set. Part 11f turns these questions into a repeatable decision.1
Where Campux lands, and why
The running client gives the spectrum somewhere to bite. Campux Retail — forty stores, one storefront, a November peak and a January trough — has two workloads that want two different rungs, and the mistake most beginners make is putting both on whichever rung they learned first.
Two workloads, two rungs, each chosen by appetite
The storefront is a web app, so the team tests App Service on a Standard plan. The plan supports rule-based autoscale and deployment slots, both useful for a seasonal surge and staged releases. The team still configures scaling and tests a slot swap. App Service is not a VM placed inside the app subnet from Class Ten: optional VNet integration lets it make outbound calls to private resources through a delegated subnet; a private endpoint is a separate inbound feature. Parts 11a and 11b show the plan and app separately.
The POS batch job is an existing three-hour program that depends on its OS environment and data disk. A right-sized VM is a practical first migration choice. Schedule both its start before the job and a deallocating shutdown afterward; check the run succeeds and account for disk costs even when compute is stopped. This is a workload-specific decision, not a rule that all three-hour jobs need VMs. Part 11d explains VM operations.
Two workloads, two rungs, each chosen by appetite. The parts ahead give each one its hands-on build; this hub is where you learn to make the call.
Does this even need to be a VM?
Finance points at always-on VMs. You inspect what each machine actually runs and when. A web app may move to App Service; a brief event may fit a scale-to-zero Functions plan; a VM that needs OS control may be right-sized and scheduled. Test performance and total cost before claiming savings.
Choose a first build path
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Storefront: supported web runtime Legacy till: requires guest-OS component Queue workers: identical replaceable machines
Choose the matching child class for each workload.
Follow the App Service lab for the storefront or VM patch lab for the legacy host.
Write which operating chores remain with you before creating resources.
On your own: a fourth workload. A weekly sales report runs for ten minutes every Monday and nothing else. Which part do you read first, and why?
Check your reasoning after you finish
On your own: Part F first, because a short scheduled job is exactly where the shortlist matters; it compares timer-driven options with keeping a machine running all week. Start with App Service for the supported storefront, a VM for the demonstrated OS requirement, and investigate scale sets for the replaceable VM workers. These starting choices still need cost, availability and capacity checks.
Examination
Four drills, then two situations. These test the judgement the whole track is built on; the hands are built in the six parts. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
C. A queue event with only seconds of processing fits a scale-to-zero Functions plan. That avoids paying for idle compute capacity, though storage, logging, and connected services may still cost money. A, B, and D keep reserved capacity for a brief, occasional job. Confirm the current plan's trigger support, networking, limits, and costs before deploying.
C. App Service fits a managed web app. Standard supports rule-based autoscale and deployment slots, which address the two stated requirements. Basic can be scaled manually but does not offer those features. The team must still set scaling rules, test release swaps, and price the plan. Part 11a explains the tier choice.
OS patching, load balancing, and the underlying VMs and runtime. Those are the chores the PaaS bargain takes off your plate. The two you keep are the two that were always yours: your application code, and the scaling rules — App Service runs the autoscale machinery, but you decide when it should add an instance and when it should stop. Confusing "Azure runs autoscale" with "Azure decides my thresholds" is how a storefront either fails to scale for November or scales into a surprise bill.
COMPUTE PLAN — Campux
1. Storefront -> App Service, Standard, autoscale for November.
2. POS nightly reconciliation (~3 hours in one run) -> Azure Functions, legacy Consumption.
3. Internal admin tool -> App Service, its own Standard plan.
4. Shared dev VM -> auto-shutdown schedule at 19:00.
Line two. The legacy Consumption Functions plan defaults to a five-minute execution timeout and can be configured up to ten minutes. A single three-hour invocation would time out. Flex Consumption and Premium have different timeout behavior; this answer does not rule out all Functions designs. The team could also split work into smaller durable steps or consider a container job or VM after checking dependencies.
Check the specific hosting plan, one-run duration, failure recovery, and billing before moving a nightly process. “It runs only once a day” is not enough information to choose a platform.
Separate the two questions the invoice is blurring. Right-sizing is about the machine being the correct size; this bill is about it being on when no work is happening. The VM can be perfectly sized and still cost four times too much because it runs 24 hours for 3 hours of work. Your manager is right that it was sized, and that is not the problem in front of them.
Diagnose the VM state first. If it remained running or was only shut down inside the guest OS, compute charges can continue. Check its power state and billing before assuming an absent schedule is the cause. The VM needs to be deallocated outside the job window to stop compute billing; disks and some other resources still cost money.
Fix the whole schedule. Arrange an automated start before the job, confirm the job completed, then deallocate the VM after its window. Built-in auto-shutdown can handle the last step; use an appropriate scheduler for startup. Monitor missed starts and overruns so saving compute time does not silently break reconciliation.
This is fashion arguing with fit. Kubernetes is genuinely excellent for a certain scale and shape of problem, and it is also a large standing set of chores — cluster upgrades, node pools, networking, the people who understand all of it on call. "Industry standard" describes what large engineering orgs run; it does not describe what a six-person team serving one storefront should carry.
Answer in chores and people, not status. App Service already gives the storefront autoscale, slots and TLS with almost no operational burden. Moving to AKS would add an entire platform for the team to run, in exchange for flexibility this workload does not need. The right question is never "what do serious engineers use" but "what does this workload need, and what will running it cost us in attention?"
Concede where the argument has a future. If Campux's needs grow — many services, complex orchestration — containers become worth revisiting, and Class Twenty-Seven prices exactly that decision honestly, including the people-cost. Part 11f of this class lays the same choice out as a framework. Today, choosing App Service is not choosing "beginner"; it is choosing the fewest chores that do the job, which is the most senior instinct there is.
Five things worth carrying out of this hub
- Compute runs a workload. Choose it by trigger, run time, OS needs, connections, scaling, and cost.
- App Service is a strong web-app candidate; its plan determines available features and cost. ASE is specialized.
- Virtual machines and scale sets are the owned car and the managed fleet: full control, and the full chore list that comes with it.
- Check what you manage, what Azure manages, and how the selected plan scales. Functions plans have different timeout and billing behavior.
- Choose by appetite for chores, not fashion. Part 11f makes that a decision you can defend, not a mood.
- Azure Functions hosting plans differ: compare current timeout and scaling limits. App Service distinguishes manual scaling, rule-based autoscale, and traffic-based automatic scaling. Its VNet integration is for outbound connections. Check these plan-specific details before repeating an exam shortcut in a real design. ↩
Choose between a VM, a scale set and App Service for a given workload, and defend the choice.