Begin with the work, then compare the services
The manager points to the new application and asks, “Can we put it on Kubernetes?” Ada asks what the application actually needs. It is a small supported web app, has no operating-system dependency, and the team has not operated a cluster before. She starts with a managed web platform and records what would change her decision. A defensible choice begins with this one workload and its operators, then compares the services that can meet its requirements.
For each remaining option, compare total cost, available capacity, team skills, deployment and rollback, monitoring, and who patches the operating system. A managed service often removes work your team does not need to own, but it is not automatically cheapest or suitable for every runtime. The decision is the least operational burden among options that meet the measured requirements, at an acceptable cost and risk.
Build a shortlist, then test it
Some candidates below (Functions, Container Apps, AKS) are taught later, in Classes 27 and 41. Treat them here as names on a shortlist with known trade-offs. This part asks for a written, reviewable choice, not for skill with services you have not met yet.
Web app or API? Start by checking App Service and, if the app is already containerized, Container Apps. Scheduled or event-driven job? Check Functions and Container Apps jobs; App Service WebJobs may fit an existing App Service estate. A three-hour duration alone does not force a VM: Azure Functions' timeout depends on its hosting plan, while Container Apps supports scheduled jobs. Verify the exact plan, execution behavior, startup time, and price.1
Needs VM-level operating-system control? Compare a VM and a scale set if you need multiple elastic machines. Needs Kubernetes controls? Compare AKS, including the team and cluster operations it requires. Needs a single-tenant App Service platform or physical-host isolation? Compare ASE v3, and choose its separate dedicated-host option only for a documented physical-host requirement. A normal ASE can have public inbound access, so choose the network configuration separately. Do not accept or reject a service by its label alone; test the written requirements against current service limits and total costs.2
Start with a requirement. Keep more than one option until you test the trade-offs.
Play it through
Four minutes. Place a legacy batch job whose licensed software requires guest OS access, then choose hosting for a standard storefront. For each, name the requirement behind the choice.
This part is a decision exercise. The individual services have hands-on lessons elsewhere in the course. Here, practice writing requirements and comparing two viable services before provisioning anything.
What each candidate asks of your team
Use this as a first shortlist, then verify current features, limits, pricing, and responsibilities for the exact plan and region. The same workload can have several valid choices. An ASE remains App Service, but single-tenant deployment, internal versus external inbound access, and optional physical dedicated hosts are distinct decisions.
| Candidate | Consider when | Your team still owns |
|---|---|---|
| Functions | Event-driven code or scheduled work; verify hosting-plan timeout and behavior | Code, configuration, dependencies, monitoring, and retries |
| App Service | Web app or API without guest OS control | App, configuration, deployment, access, and scale |
| ↳ ASE v3 | Written single-tenant App Service or ASE-specific need | App Service work, environment cost, and chosen network model; dedicated hosts are optional |
| Container Apps | Containerized app or scheduled/event job without managing a cluster | Image, app behavior, configuration, scaling rules, and monitoring |
| AKS | Kubernetes features and control justify cluster operations | Cluster, nodes, workloads, policies, and upgrades |
| VM / scale set | Guest OS or VM-level control is required; use a scale set for a fleet | Guest OS, patching, application, backup, and recovery |
Two mistakes remain common. One is taking on VM or cluster work without a requirement that needs it. The other is choosing a managed plan without checking its runtime, scale, network, and recovery limits. Neither can be settled by the product name or a single hourly price. Write the requirement and test the candidate that claims to meet it.
Defending the call in the room
In a design review, state the workload first: “This is one stateless web app with no guest OS dependency. App Service meets its tested traffic and network needs. AKS would give Kubernetes control, but we have no requirement for it and would need to operate a cluster.” That is a reasoned recommendation, not a universal ban on AKS.
For a three-hour scheduled job, do not say “Functions cannot run that long” without naming the plan. Check the current timeout and execution constraints for the proposed hosting plan; also consider a Container Apps job if the workload can be containerized. If a licensed component requires guest OS access, that is a concrete reason to compare VMs. The Container Apps versus AKS versus App Service note gives another comparison to examine.
Campux's whole estate, placed by the framework
The storefront is a web app with seasonal demand and no guest OS dependency, so App Service is a candidate after testing its scale and networking. The nightly price import runs for a few minutes on a timer, so a Functions plan is a candidate after checking its timeout and retries. For this exercise, the POS reconciliation uses a licensed Windows component that requires guest OS installation and cannot be repackaged for a managed container service. That stated dependency makes a VM defensible; its three-hour duration alone would not.
A developer proposes AKS for the storefront because it is familiar. Ask what Kubernetes capability the app needs and who will run the cluster. If none is required, compare App Service's cost and operations with AKS before choosing. If the POS software changes later and no longer needs the guest OS, reopen its hosting decision too. A good design can change when its constraints change.
What you carry out of Class Eleven
Class Eleven covered managed web hosting, single-tenant App Service, individual VMs, and VM fleets. Each gives a different amount of platform control and operating work. Your job is to state the workload, rule out products that cannot meet its hard requirements, and compare the remaining options on cost, recovery, and team effort.
Write the decision down: what was required, what you tested, why you chose this service and plan, and what would make you revisit it. Class Twelve applies the same method to storage. You do not need to memorize one answer for every shape of app; you need a repeatable way to reach and defend a sound answer.
The architecture review where "why not Kubernetes" comes up
You present an App Service design and the senior architect asks why it is not on AKS. Explain the requirements you tested: traffic, network access, recovery, deployment, and OS dependencies. If App Service meets them, ask which specific requirement AKS would meet better and what cluster operations would cost the team. Record the comparison. A different answer may be right if the team's existing platform, skills, or workload constraints change.
Write a decision another engineer can review
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Storefront: supported runtime, no custom OS component Team: two engineers; no cluster operations experience Need: deploy reviewed code and recover a failed release
Write the hard requirements separately from preferences.
Complete an App Service decision with one rejected alternative.
Name a new requirement that would cause you to revisit that decision.
Check your reasoning after you finish
App Service is a reasonable first candidate here. A VM introduces OS chores with no stated need; AKS adds cluster operations. A proven unsupported runtime, special networking requirement or workload shape can change the choice.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
C. First rule out options that fail a hard requirement. Then compare the viable options on cost, recovery, and the operating work your team will own. A product's power, popularity, or maximum scale matters only when the workload actually needs it. One workload can have more than one sound answer.
C. Azure Container Apps is the strongest first candidate for the stated containerized workload and desire to avoid cluster operations. Verify the app's scale rule and whether zero replicas are appropriate. A VM scale set returns guest OS work to the team. AKS brings Kubernetes operations the question says the team does not want. ASE v3 is single-tenant App Service; physical dedicated hosts are optional and it is not chosen just because the workload is a container.
Guest OS control, a plan-specific timeout, and real Kubernetes needs all affect the shortlist. The timeout rules out that proposed Functions plan; another Functions plan or a Container Apps job may still fit. The two other statements describe image or status preferences, not a workload constraint. Name the exact service feature or limit before eliminating a product.
COMPUTE PLACEMENTS — Campux
1. Storefront (web app, seasonal surge) -> App Service Standard.
2. Nightly price import (~4 min, timer) -> Functions, consumption.
3. Internal reporting site (dozens of users) -> AKS cluster.
4. POS reconciliation (licensed guest-OS component) -> right-sized VM.
Line three. The reporting site has no stated Kubernetes need, yet its team would operate a cluster. Shortlist a simpler web host and test its network, access, scale, and recovery requirements first. The other placements have stated reasons: a web storefront, a short timer job, and a licensed component that needs guest OS access. A three-hour duration alone would not justify line four's VM.
Consider the consequence. The reporting site runs fine on AKS — that is the trap — but the six-person team now operates a cluster, its upgrades, its node pools and its on-call, all to serve an internal page a single App Service app would have hosted for a fraction of the attention. The cost is not an outage; it is a permanent tax on the team's time, justified by nothing the workload actually needed. Catching "this doesn't need that rung" is the entire job the framework trains.
Take consistency seriously. If the company already operates AKS well, using its established deployment and monitoring tools may save work. Ask what that platform provides this app and who handles its upgrades, security, and incidents.
Compare the two real options. List the app's traffic, network, recovery, and release requirements. Check that App Service and the existing AKS platform can meet them. Compare the full cost and the team's operating work, including any new AKS cluster or App Service setup. Do not choose from reputation alone.
State a revisit trigger. If App Service wins, document why and keep common standards for deployment and monitoring. Reconsider AKS when a requirement changes, such as needing orchestration across several services. Class Twenty-Seven examines that platform in detail.
Investigate the outage first. Ask what failed, how it was detected, and how service was restored. A VM rule only helps if guest OS control addresses that cause; it does not automatically prevent a repeat.
Compare responsibilities. A VM gives the team OS and patch control along with the work of patching, backup, monitoring, and recovery. A managed service handles some of that platform work, while the team still owns its application and configuration. Either option can fail if its recovery plan is untested.
Propose a measurable decision. Set a recovery target, test backup and restore, monitor the failure mode, and compare a VM with managed candidates against the workload's requirements. Keep a VM where its control is needed. Document the choice and revisit it after an incident or requirement change.
Five things worth carrying out of Part F
- Write the workload's trigger, duration, runtime, network, scale, recovery, and isolation needs before selecting a product.
- Shortlist more than one candidate when possible: Functions or Container Apps jobs for scheduled work, App Service for web apps, AKS for Kubernetes needs, VMs for guest OS control.
- Check the exact hosting plan's limits. A three-hour job does not automatically require a VM, and ASE's single-tenant platform is distinct from optional physical dedicated hosts.
- Compare total cost, startup and recovery behavior, team skills, and ongoing operations among candidates that meet the hard requirements.
- Document the chosen service and plan, the alternatives rejected, the evidence, and when the decision should be revisited.
- Microsoft documents plan-specific Azure Functions timeouts, scheduled Container Apps jobs, and App Service WebJobs. Check the current limits and pricing of the exact candidate plan. ↩
- Microsoft's ASE overview distinguishes its single-tenant platform from optional dedicated physical hosts. Availability, network controls, team skills, and migration constraints can change a close compute decision, so validate each against the current service documentation. ↩
Write a workload's hard requirements, compare the compute services you have met so far, and defend a written choice.
Play the lesson above to stamp this class.