Virtual machines, containers and functions compared

Virtual machines virtualise the hardware

A virtual machine is a computer that happens to be software: it boots its own operating system, and everything above the hypervisor is yours to install, configure and patch. That is the trade in one sentence. You get compatibility with anything — a kernel-level driver, a registry-editing scheduled task, a runtime that went out of support years ago — and in exchange you own the operating system for as long as the machine exists.

This is why lift and shift lands on virtual machines. Read a requirements list for anything BELOW the application, and each item is an argument for infrastructure as a service, because no higher-level option will let you reach down there.

Containers virtualise the operating system

A container image carries an application and its dependencies, and containers on a host share that host's operating system kernel rather than each booting one. Every visible property follows from that single fact: they start in seconds because there is no operating system to boot, they pack densely because there is no per-instance kernel reserving memory, and their isolation is weaker than a virtual machine's because the kernel they share is a boundary they have in common.

Azure offers two ways to run them and the split between the two is examinable. Azure Container Instances runs a container with no orchestrator for you to operate — burst capacity, a batch job, one isolated task. Azure Kubernetes Service is the managed orchestrator: Azure runs the control plane, you run the workloads, and what you get for the extra operational surface is scheduling, self-healing, rolling upgrades and service discovery. Containers change the packaging; they do not answer the question of how many replicas to run, which is still yours or an autoscaler's.

Functions remove the server from view

Azure Functions runs a piece of code when something happens. The trigger can be an incoming HTTP request, but it can equally be a timer, a message arriving on a queue, a new blob in a container, or an event published by another service — and treating HTTP as the only trigger is the misconception the exam checks for. Serverless in Azure means three things at once: no infrastructure for you to manage, scaling driven automatically by demand, and billing tied to executions rather than to uptime.

That third property is the discriminator, and it is worth over-weighting when reading a stem. A workload that is event-driven, short-lived and idle most of the time costs almost nothing on a consumption plan and costs a full day's billing on a virtual machine sized for its busiest hour. When a question describes bursty work and then mentions paying for what is used, it has already told you the answer.

Reading the scenario

Three phrases decide most of these. Anything below the application — drivers, the registry, an unsupported runtime, a required patch level — means a virtual machine. Packaging with dependencies, conflicting library versions, fast start-up and density mean containers, with the orchestration vocabulary deciding which of the two container services. Event-driven, intermittent, and paying only for what runs means Functions. Everything else in the option list is usually a real Azure service placed one level away from where it belongs.