Full Width Blue Boxes

Microsoft carry out periodic updates of the underlying fabric hosting Azure VMs to perform things like patch updates and service improvements. Microsoft call these ‘planned maintenance events’.

In addition, there can be ‘unplanned maintenance events’, carried out to resolve things like hardware failures.

To help protect VMs from going offline in these situations, Azure fabric is spread over ‘update’ and ‘fault’ domains.

VM Availability sets are used to ensure resilience by ensuring similar groups of VMs are spread across multiple update and fault domains.

As an example, an n-tier application would consist of multiple availability sets, one for each tier. To ensure SLAs for Azure VMs are met, at least two VMs must be added to an availability set. For these reasons, correct design of availability sets is critical to ensuring availability of service.

A key benefit of public cloud services such as Azure is their capability to support ‘elastic’ workloads. These are workloads that can basically scale up or down based on demand, enabling workloads to run on a minimal footprint (and therefore cost) until such time as additional resource is required to support a short burst of activity. An example of this would be an online retailer with seasonal spikes in business.

Depending on your needs, elastic computing can be a really powerful technology, although it doesn’t work well for scaling conventional application workloads such as SQL Server or Exchange.

However, elastic computing shines for applications where you can divide the work to be done among a number of identical applications or services running on different machines.

VM scale sets provide a way of enabling a set of identical VMs to scale out or in based on demand. With all VMs configured the same, scale sets are designed to support true autoscale, with no pre-provisioning of VMs required.

A key design decision is whether scale sets are suitable for a workload, then if so, what performance triggers should be used to define a scale set.

Once you have decided on an applications suitability for a scale set, the next design decision is to consider if scaling should be automatic, and if so, what triggers should be used. Auto scale triggers can be set on various performance triggers such as CPU utilisation, memory utilisation or message queue length. Deciding which triggers to use is key to ensuring the workload scales at the right time.