Windows Azure Autoscaling–available now!

  • Article

In my white paper on IT energy efficiency, I wrote about the need for software developers to design their applications to dynamically scale, so we aren’t simply trading idle servers for idle VMs when applications move to public or private clouds.   Unlike physical server infrastructure which is often statically assigned to specific applications for years, private and public clouds typically provide incentives for developers to scale up and down dynamically because the billing increment can be quite small – often by the hour.  So you can control costs and reduce the environmental impact of your apps at the same time – if you design them appropriately!

Up until now, scaling instances on Windows Azure was a manual process or required you to develop your own functionality to do this automatically.

In response to this opportunity for improved resource efficiency and utilization, the Microsoft Patterns & Practices team has worked with Microsoft Consulting Services and an advisory board of Windows Azure customers to develop the Windows Azure AutoScaling Block, which RTW’ed last week as part of the new Enterprise Library Integration Pack for Windows Azure.

WASABi, as it’s affectionately known, helps developers to automatically scale both web and worker roles in Windows Azure by dynamically provisioning/decommissioning roles or throttling. These scaling actions are based on timetables or on metrics collected from the application and/or Windows Azure Diagnostics.

WASABi addresses the following scenarios:

1. Autoscaling both web and worker roles in Windows Azure by dynamically changing instance counts or performing application throttling.

2. Autoscaling Windows Azure roles based on timetables.

3. Autoscaling Windows Azure roles based on metrics collected from the application and/or Windows Azure but constrained by upper and lower bounds on the instance count per role.

4. Preventing fast oscillations in the number of role instances through the use of a “stabilizer”. The stabilizer can also help to optimize costs by limiting scaling up operations to the beginning of the hour and scaling down operations to the end of the hour.

5. Monitoring and logging autoscaling activity.

6. Sending notifications to preview any scaling operations before they take place.

7. Encrypting the rules and other configuration in Windows Azure blob storage or in local file storage.

8. Managing the autoscaler configuration by using Windows PowerShell.

WASABi scales apps through rules that a developer and/or an IT Pro creates and updates over time.  The excellent blog post by Julian Dominguez notes that there are 2 types of rules in WASABi:

  • Constraint Rules- Defines lower and upper boundaries for the number of instances that should be present at all times. You can define boundaries that apply at all times, and you can also define boundaries based on recurrence patterns, to proactively scale your application based on expected load.
  • Reactive Rules- Allows you to scale your application based on conditions, such as when a certain performance counter goes beyond a certain level (e.g. average CPU usage for all instances of a role is greater than 80%), when a Windows Azure Queue has too many messages, or if you have your own metric you are interested in, you can extend and support it.

The recommended way to obtain the Enterprise Library Integration Pack for Windows Azure is as NuGet packages. Alternatively, you can download self-extracting zip files with binaries, sources (including tests) and the reference implementation from MSDN.  The reference implementation also includes an Autoscaling management site, which lets you do authoring of the rules, and monitoring of the autoscaled application, so you can see how Tailspin (the reference implementation application) responds to load.  The configuration tool is available as a Visual Studio extension package (VSIX) from the Visual Studio Gallery.

The buzz and uptake on WASABi has been very positive thus far and which leads me to believe that WASABi will be a key ingredient for any Windows Azure app that expects (or hopes) to scale up significantly.  Next up – Pickled Ginger?

P.S.   If you were wondering, the root pictured above is the real Wasabi root, which you can read more about here.