Enterprise Library Integration Pack for Windows Azure™ is finally here! Most of the Application Blocks you already love work well in the Cloud, so we had some time to focus on all-new Application Blocks designed specifically for Windows Azure, based on strong customer feedback.
You can read the official announcement in Grigori’s post.
The one we put a lot of emphasis on in the last few months, is the Autoscaling Application Block, or just “WASABi”, and that is the focus of this post. WASABi lets you add automatic scaling behavior to your Windows Azure applications, based on rules.
WASABi can automatically scale your Windows Azure application based on rules that you define specifically for your application. You can use these rules to help your Windows Azure application maintain its throughput in response to changes in its workload, while at the same time control the costs associated with hosting your application in Windows Azure. Scaling operations typically alter the number of role instances in your application, but the block also enables you to use other scaling actions such as throttling certain functionality within your application.
Although we created WASABi in a way that is easy to set up and start autoscaling your application immediately, this is not a service, but a component. YOU can decide how YOU want to host the Autoscaler, and YOU can create extensions through code to satisfy your specific business needs. YOU own the binaries and can extend them, and YOU own the source code if you need to update it!
There are 2 types of rules in WASABi:
We had lots of discussions and iterated several times over this: Autoscaling is accomplish by the developer AND the IT pro. In some organizations this could be the same person, but in many others they value a clear separation for the features that each of them control.
IT pros will be able to work with the tools they are more comfortable with, in order to monitor and maintain the Autoscaling process in a healthy state. They will be able to update the rules or the references to the target application (i.e. Storage account connection strings, etc) without ever needing to open Visual Studio nor re-deploy the Autoscaler.
Although all the runtime information is included in XML files that you can continuously update, as they can be hosted locally or in a Windows Azure Blob, we are shipping PowerShell cmdlets to let you easily enable/disable certain rules, turn on/off the rule evaluation process, change stabilization settings, encrypt etc, for standard scripting automation (you can think SCOM or anything like that).
Of course, we want to be very transparent for what is going on. We are logging with several levels of verbosity, all that is going on with the Autoscaler. The log messages will not help only humans, but in almost all messages, we also provide structured JSON that can be consumed by a tool.
In this release at least, we are not providing a full-fledged monitoring tool, but we wanted to give you a feel of what that would look like if you want to write one for yourself. The Tailspin Reference Implementation, includes a sample monitoring page that consumes the structured log messages and displays graphs to make IT pros life easier. Remember, this is just a sample, there is lots of room for improvement. Maybe the EntLibContrib community (that means you) can take up this challenge?
Yes, you can. We are including a Reference Implementation (RI) in the downloads. This is an application (Tailspin, originally from the Windows Azure Guidance) which is automatically scaled by the block. We also included an Autoscaling management site, which lets you do authoring of the rules, and monitoring of the autoscaled application, so you can see how Tailspin responds to load.
Try it out, let us know, and spread the word!