Hosting an application: web apps, containers and virtual machines

A continuum of control against effort

Hosting options in Azure are not a list of alternatives so much as a line. App Service manages the platform and leaves you the least to run; container platforms give portability and density, with orchestration as a separate decision; virtual machines give total control and, inseparably, total responsibility. The general rule for this exam and for real designs is the same: choose the highest-level option the application's requirements still fit inside.

The corollary is the sentence that resolves most of these questions. The more a platform manages for you, the less it lets you change. So a requirement about scaling, patching, certificates or release mechanics is an argument for the platform, and a requirement about anything underneath the application is an argument against it.

What App Service gives you that you would otherwise build

App Service is the managed host for web applications and APIs written in the supported runtimes. Out of the box it gives managed certificates and HTTPS, autoscaling rules, and deployment slots — a slot is a second copy of the application you can deploy to, warm up, and then swap into production, with the previous version left in the slot so a bad release can be swapped straight back. Building that release choreography by hand on a virtual machine is a project; here it is a feature.

What you give up is the box. You do not get remote desktop or SSH access to the instance, and that is the bargain rather than a limitation: giving up the machine is precisely what buys you a platform somebody else maintains. App Service can also run containers, which is worth knowing because it makes "we containerised it" a weaker signal than candidates expect — a single web application in a container is still a web application.

Containers: one of them, or a fleet

Azure Container Instances is the fastest way to get a container running with nothing to operate: no cluster, no scheduler, no node pool. Azure Kubernetes Service exists for the case where something has to keep deciding where workloads run, restart them when they fail, upgrade them without downtime and let them find each other by name. Azure runs the control plane; you run and pay for the nodes and the workloads on them.

The tell in a question is vocabulary rather than scale. Scheduling, self-healing, rolling upgrades and service discovery are the definition of orchestration, and any stem using two or three of them has named Kubernetes Service. A stem that says one job, one container, no cluster to manage has named Container Instances just as clearly.

Where the responsibility boundary lands

The shared responsibility model is easiest to hold as a stack. The physical datacentre, the hosts and the network under them are always Microsoft's. Your data, your identities and who has access to them are always yours, in every service type. The operating system, the runtime and the middleware in between move: on infrastructure as a service they are yours, on a platform service they are Microsoft's, and choosing a hosting option is therefore also choosing how much of that middle you are volunteering to own.

The guest operating system is the clearest example, and the one the exam uses. On App Service and Azure Functions the platform is maintained for you. On a virtual machine it is yours — and Azure's automatic guest patching does not change that. It is a feature you enable and then verify, which moves the labour rather than the responsibility.