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:
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.
For those looking to go this automatically using a cloud based service, we have released AzureOps, We enable the notion of Smart Scaling that allows you to create scaling units that scale up or down together or in isolation. Check it out here Opstera recently shipped a zero install SaaS service called AzureOps to perform smart scaling for Windows Azure applications. Check it out here www.opstera.com/.../Azureops