The ability to dynamically scale to a public cloud was one of the mantra’s I used to hear a couple of years ago. When reality struck and customers realised that there monolithic applications wouldn’t be suitable for this construct they realised they would need to re-architect.
Wind forward a couple of years and the use of Microsoft Azure Auto Scaling has become a reality, so with this in mind I thought it would be a good idea to share a blog post on the subject.
What Is Auto Scaling?
Auto Scaling is the process of increasing either the number of instances (scale out/in) or the compute power (scale up/down) when a level of demand is reached.
Scale Up/Down
Scale Up or Down is targeted at increasing or decreasing the compute assigned to a VM. Microsoft have a number of ways in which you can ‘scale up’ on the Azure platform. To vertically scale you can use any of the following:
- Manual Process – Simple keep your VHD and deploy a new VM with greater resources.
- Azure Automation – For VM’s which are not identical you can use Azure Automation with Web Hooks to monitor conditions e.g. CPU over ‘x’ time greater than ‘x’ and then scale up the VM within the same series of VM
- Scale Sets – For VM’s which are identical you can use Scale Sets which is a PaaS offering which ensures that fault, update domains and load balancing is built in.
Note that using a Manual Process, Azure Automation and Scale Sets to resize a VM will require a VM restart
The diagram below provides a logical overview of a Scale Set.
Scale Out/In
Scale Out or In is targeted at increasing or decreasing the number of instances, which could be made up of VM’s, Service Fabric, App Service or Cloud Service.
Common approaches are to use VM’s for applications which will support Scale Out/In. Typically a piece of middleware that performs number crunching but holds no data or perhaps a worker role that is used to transport data from point a to be.
For websites it is more common to use App Service ‘Web Apps’ which in a nutshell provides a PaaS service and depending on the hosting option chosen Standard, Premium or Isolated will dictate the maximum number of instances and Auto Scale support.
Considerations
Auto Scaling requires time to scale up or out, it doesn’t respond to a single spike in CPU usage, it looks at averages over a 45 minute period. Therefore it is suggested that if you know when a peak workload is likely it could be more efficient to deploy Auto Scaling using a schedule.
To ensure that a run away process doesn’t cause costs to spiral out of control, use tags, a different Azure subscription, email alerting or perhaps even limit the number of instances on Auto Scale.
VMFocus 