Application users can be a tough crowd to please, they demand systems that perform well. Many applications are subject to variable workloads often experiencing unpredictable peaks in activity. Accommodating these varying workload profiles on-premise can be expensive with resource laying idle during periods of low demand.
Even with predictable workloads, procuring new hardware for on-premise deployments can be costly and involve long lead times. The elasticity and scalability features of Azure helps enterprises meet the demands of their application peak workloads whilst delivering consistent performance with optimized costs.
When we talk about scalability, we’re describing Azure’s ability to accommodate the resource demands of an application or solution. When we talk about Azure’s elasticity, we are describing the ability to scale that resource capacity up/down or in/out to meet changing demand. The beauty of Azure is that you only pay for what you use with usage billed on a ‘per second’ basis. The moment your application or solution releases resource and capacity you are saving money.
Autoscaling is a built-in feature of many Azure services allowing for dynamic scaling of application infrastructure or services in response to an autoscaling schedule or a breach of performance metric thresholds. An example performance metric could be the number of active users connected to a web server or the host virtual machine CPU utilisation. Autoscaling is flexible enough to allow users to define their own custom performance metrics that are meaningful to their applications.
‘Scaling Up’ is the term we use when adding more CPU or memory resources to a given service instance to meet demand, ‘Scaling Down’ is the opposite, reducing the resource capacity of an instance. ‘Scaling up/Down’ is also known as Vertical Scaling. An example of ‘Scaling Up’ would be changing an Azure Virtual machine from a Standard_A1_v2 with 1 vCPU and 2GiB memory to a Standard_A2_v2 with 2 vCPU’s and 4 GiB memory.
Beware when looking to scale up or down resources, this cannot always be achieved without downtime. Azure VM’s require a restart whilst the Azure SQL databases and Azure App Services experience short service interruptions.
1.1 Scaling up an Azure virtual machine
‘Scaling In/Out’ also known as ‘Horizonal Scaling’, is considered a more modern approach to application architecture allowing capacity to be flexed without downtime. ‘Scaling out’ sees capacity increased by adding instances running identical services in parallel. ‘Scaling in’ sees capacity reduced by removing those instances. Scaling In/Out is a feature of both traditional Azure infrastructure services as well as the cloud native serverless and container platforms.
Azure Virtual machines can scale horizontally using scale sets, allowing managed groups of up to a thousand identical load-balanced VM’s to flex. Azure Scale Sets support both layer-4 load balancer (including session affinity) and the layer-7 Application Gateway for more advanced traffic distribution and security. With the ability to distribute VM’s across multiple availability groups in the same region, scale sets are a great way to build resilience into application design. These fantastic Scale Set features are all available at no extra cost, you only pay for the underlying compute resources.
1.2 Scaling up load balanced Azure virtual machines using Azure scale sets
The serverless Azure Web App service can horizontally scale the number of VM’s in the service plan by as many as one hundred depending on pricing tier. The Azure Serverless Kubernetes and Serverless apps have the unique feature of being able to scale to zero with the app or containers only running when triggered by an event.