CH04-04: Virtual Machines and Control Boundaries

Goal

The chapter has moved from managed web hosting to event-driven execution and containers. Now we reach the compute option that feels most familiar to many teams: virtual machines.

Azure Virtual Machines are not outdated. They are also not the default answer for every workload. They are the right answer when the workload needs the control and compatibility they provide.

The durable idea is:

Virtual Machines are for control and compatibility, but that control moves more operations back to the team.

The Short Version

An Azure Virtual Machine gives you a virtualized server in Azure. You choose the operating system, size, disks, network placement, installed software, and runtime configuration. Azure provides the physical datacenter, host infrastructure, and virtualization platform. Your team manages much more of what happens inside the machine.

VMs are often useful for:

• Legacy applications that cannot yet run on managed services.

• Software that needs OS-level configuration.

• Specialized runtimes, agents, drivers, or installed components.

• Licensing or vendor support constraints.

• Migration paths where rehosting is the sensible first step.

The architecture question is not whether VMs are allowed. The architecture question is whether the need for control is strong enough to justify the operating work.

The Responsibility Split

Use this model when explaining VMs:

Azure manages:
  Physical datacenter
  Physical hosts
  Base virtualization platform
  Regional infrastructure services

Team manages:
  Operating system configuration
  Patching and updates
  Runtime and installed software
  Security hardening
  Application deployment
  Backup and recovery
  Scaling and availability design
  Monitoring and incident response

Compared with App Service, Functions, or Container Apps, a VM gives you more control over the environment. That control is valuable only if the workload needs it and the team can operate it.

When VMs Make Sense

VMs are a good choice when a managed compute service cannot satisfy a real requirement.

Common examples include:

These are practical reasons. They should be written down as architecture constraints, not hidden behind "we always use VMs."

What the Team Must Own

The VM choice brings a longer operating checklist.

At minimum, the team should plan:

• OS patching and security updates.

• Baseline hardening and configuration management.

• Disk layout, backup, restore, and data protection.

• Availability zones, scale sets, load balancing, or other availability patterns when needed.

• Monitoring for CPU, memory, disk, network, OS health, and application health.

• Vulnerability management and endpoint protection.

• Image management or build automation.

• Access control, bastion or private access, and emergency operations.

• Recovery objectives and disaster recovery patterns.

This is why a cheap-looking VM can be expensive in practice. The invoice may be simple. The operating model may not be.

Lift-and-Shift Is a Stage, Not a Strategy by Itself

Rehosting a workload on VMs can be a smart migration move. It can reduce datacenter pressure, unblock a timeline, or move a system closer to Azure dependencies.

But lift-and-shift should not automatically become the final architecture.

After migration, review the workload:

• Is the application still changing often?

• Could the web tier move to App Service?

• Could background jobs move to Functions or Container Apps?

• Could a legacy dependency be removed or isolated?

• Are VM patching, backup, and recovery working well enough?

• Is the cost of operating the VM still justified?

Sometimes the answer is to keep the VM. Sometimes the answer is to modernize one component at a time. A mature architecture can include VMs without being VM-centered.

Example: Legacy Reporting Engine

Imagine the SaaS platform has a legacy Windows reporting engine. It depends on installed report designer components, writes temporary files to local disk, and uses a vendor library that is only supported on a full Windows Server environment.

Forcing this component into App Service or Container Apps may create more risk than value. A VM may be the right near-term boundary:

Modern application services
	|
	v
Internal API or queue
	|
	v
Azure VM: legacy reporting engine
	|
	v
Report output in storage

The VM should still live inside the governed Azure environment. It needs private networking, managed identity or controlled secrets where possible, monitoring, backup, patching, and access controls. Calling it temporary does not make it safe by default.

The design should also include a review point. If the vendor library changes, the reporting engine may later move to a managed service or containerized runtime.

Common Mistakes

• Choosing VMs because they look like the old datacenter.

• Forgetting patching, backup, availability, and recovery design.

• Treating lift-and-shift as the final architecture without a review plan.

• Using VMs for web apps that could run more simply on managed services.

• Leaving temporary VMs outside normal governance, monitoring, and cost ownership.

If Someone Asks You

When are Azure Virtual Machines still a good choice?

A good answer is:

Azure Virtual Machines are a good choice when the workload needs OS-level control, legacy compatibility, specialized configuration, or a supported migration path that managed services cannot provide. I would use them deliberately, with a clear operating plan for patching, backup, monitoring, scaling, security, and recovery. If that control is not needed, I would usually prefer a more managed compute option.

What You Should Remember

Choose VMs when control or compatibility matters enough to justify the operating work.

Questions to Check Your Understanding

1. What kinds of requirements can justify virtual machines?

2. Which responsibilities remain with the team when using VMs?

3. Why is lift-and-shift not automatically the end state?