Azure compute: containers, virtual machines, functions, and where to host an application

Why this matters

Compute is where an application's code actually runs, and Azure offers several very different ways to run it. At one end, a virtual machine gives full control of the operating system and leaves every patch to you. At the other, a function runs a few lines of code when an event arrives and costs nothing while it waits. In between sit containers and managed web hosting. Each choice changes who does the operational work, how the bill is calculated and how quickly the application can grow.

A manager needs this to understand why one team's monthly bill is flat while another's rises and falls with traffic. A salesperson needs it to answer a customer who wants to move dozens of old Windows servers without rewriting anything. A junior administrator needs it to know that an availability set will not save an application when a whole datacenter fails, and that a VM is more than a VM: it needs a disk, a network interface and a network. Picking the wrong option means either paying for idle servers or rebuilding an application that only needed a simpler home.

The lesson

Comparing containers, virtual machines and functions

Azure's three main compute types differ in how much of the stack you manage.

Virtual machines are infrastructure as a service (lesson 4). An Azure virtual machine is a full computer emulated in software: you choose the operating system image, install whatever software you need and configure it however you like. That control is the reason to choose a VM. A legacy line-of-business application that needs a specific older operating system version and custom software from the IT team belongs on a VM. So does any task needing software that requires administrator access to the operating system. The cost of that control is responsibility: you patch and maintain the guest operating system.

Containers package an application together with its libraries, settings and dependencies. Unlike a VM, a container does not carry its own full guest operating system. Containers on a host share the host's operating system kernel, so they are small and start in seconds. Because the package travels with the app, a container runs the same way on a developer's laptop as it does in Azure. Azure runs both Linux and Windows containers. Azure has several ways to run them:

• Azure Container Instances (ACI) runs a container on demand, with no virtual machines or orchestrator to manage, and bills while the container runs. It suits a short nightly batch job.
• Azure Kubernetes Service (AKS) is managed Kubernetes. It orchestrates many containers across a cluster of nodes, with automated scaling, rolling updates and self-healing (restarting failed containers). It suits dozens of microservices run by a team with Kubernetes skills, and it is far more than one short job needs.
• Azure Container Apps runs containers on a serverless platform, so Microsoft manages the servers underneath.

Functions are serverless compute (lesson 2 introduces serverless). With Azure Functions, you write code that runs in response to a trigger: an HTTP request, a timer, a message on a queue or a new file (blob) in a storage account. On the Consumption plan, functions scale automatically and are billed per execution, so you pay nothing while no events arrive. You never patch an operating system.

A quick rule: if the requirement mentions the operating system, choose a VM. If it mentions packaging an app with its dependencies, choose a container. If it mentions running only when something happens and paying only for executions, choose a function. An always-on VM or a web app on an App Service plan runs and bills continuously whether or not any events arrive.

Virtual machine options: VMs, scale sets, availability sets and Azure Virtual Desktop

Azure virtual machines suit lift-and-shift migrations. A company moving dozens of on-premises Windows servers can recreate them as Azure VMs with the same operating systems and applications, without rewriting code. Other hosting options usually need the code adapted to the platform or repackaged as a container first.

Azure Virtual Machine Scale Sets manage a group of identical, load-balanced VMs. All the instances are created from one shared configuration, so they are consistent, and nobody configures each one by hand. Autoscale rules add instances as demand rises and remove them as it falls, or follow a schedule. A web front end whose traffic doubles every weekday afternoon is the classic case. A scale set works within one region, and can spread its instances across that region's availability zones. Resizing one VM to a larger size is not the same: it is still one machine, and it does not shrink when traffic drops.

Availability sets improve resilience inside a single datacenter. They spread VMs across two kinds of grouping:

• Fault domains are groups of hardware that share power and a network switch. VMs in different fault domains do not fail together when a rack loses power.
• Update domains are groups that Azure reboots at different times during planned maintenance. VMs in the set are spread across update domains, and Azure reboots only one update domain at a time, so two VMs running the same app reboot one at a time, never together.

An availability set never changes how many VMs are running, and it does not move or copy VMs to another region or zone. Because it works inside one datacenter, it cannot protect against the loss of that whole datacenter. For that you run the VMs in two or more availability zones, which are physically separate datacenters in the region (lesson 5).

Azure Virtual Desktop is a desktop and application virtualisation service. Users connect to Windows desktops and apps that run in Azure, so company data stays in the cloud and not on their devices. Key features:

• Windows Enterprise multi-session lets several users sign in to the same session host VM at once, which reduces the number of VMs needed.
• It can publish a full desktop or individual applications as RemoteApps, so contractors can use one Windows application without a full desktop session.
• Users connect from Windows, macOS, iOS, Android or a web browser, from personal laptops as well as office machines.

Azure Virtual Desktop is the answer whenever the requirement is "staff use a Windows desktop or app hosted in Azure". Azure App Service hosts web applications, not desktops people sign in to.

What a virtual machine needs

Creating a VM creates, or uses, several other resources. Knowing them explains both how a VM works and why it costs what it does.

• A VM size. The size, such as a general-purpose or memory-optimised size, decides how many virtual CPUs and how much memory the VM gets. You can resize later.
• An operating system image. The image decides which operating system the VM runs.
• An operating system disk. Every VM needs an OS disk, normally a managed disk that Azure stores and manages for you. The disk type, such as Standard HDD or Premium SSD, affects storage performance, not CPUs and memory.
• Data disks. Data that must survive restarts and moves, kept separately from the operating system, goes on a managed data disk: persistent block storage attached to the VM. Many VMs also have a temporary disk, which is for short-term scratch use only. Its contents can be lost during maintenance or when the VM is redeployed.
• A network interface connected to a subnet of a virtual network. The virtual network gives the VM a private IP address and lets it communicate with other Azure resources. Lesson 8 covers virtual networks.
• A public IP address, optionally, if the VM must be reachable from the internet. A public IP makes it reachable, but it does not filter who connects.
• A network security group (NSG), which holds rules that allow or deny traffic by source, destination, port and protocol. To accept Remote Desktop only from the office's address, you write an NSG rule allowing that source and nothing else.

Things a VM does not need: a management group (those organise subscriptions), an Azure Virtual Desktop host pool, or an Azure Functions hosting plan.

Hosting an application: web apps, containers or virtual machines

When the job is to host an application rather than to run a server, there are three broad routes.

• Web apps on Azure App Service. App Service is platform as a service for web apps and APIs in languages such as .NET, Java, Node.js and Python. Microsoft manages the operating system and patching; you deploy code, often straight from a code repository, and App Service can scale it. A small team that wants to publish a Python web app without managing servers belongs here. An App Service web app cannot pin an older operating system or install arbitrary software, because the platform owns the operating system.
• Containers. If the app is already packaged as a container image, it can run without the company managing VMs on Azure Container Apps or on App Service, which can run a custom container image as a web app. ACI suits single containers and short jobs; AKS suits many containers that need orchestration.
• Virtual machines. VMs host anything, including software that needs operating system access, but the company then manages the VMs and patches them. They are the default for lifting existing servers as they are.

Moving from VMs to App Service or containers trades control for less operational work. Moving the other way buys control at the price of patching.

What the exam is really asking

Questions in this area name a requirement and ask for the service. The usual pairs are:

• Specific operating system, custom software, lift and shift: Azure virtual machines.
• Run code on an event and pay per execution: Azure Functions.
• Short container job, no orchestrator: Azure Container Instances. Many microservices with orchestration: Azure Kubernetes Service.
• Web app from code, no servers to patch: Azure App Service.
• Add and remove identical VMs with demand: a Virtual Machine Scale Set.
• Survive a rack failure or planned reboots: an availability set. Survive a datacenter failure: availability zones.
• Windows desktops or apps for remote users: Azure Virtual Desktop.

The common traps are believing an availability set protects against a datacenter outage or adds VMs, thinking each container carries a full guest operating system, assuming containers run only on Linux, mixing up the VM size (CPUs and memory) with the disk type (storage performance), and keeping lasting data on the temporary disk.