This session was presented byMahesh Krishnan from Readify (@MaheshKrishnan) and focused on building robust Windows Azure apps, but in particular the benefits of elasticity. To me one of the most appealing things about cloud based apps is the ability to scale up / down as needed to meet demand, so this session was a good choice. In addition to that Mahesh showed us the application block from the enterprise library for dealing with transient errors.
Here is a pretty comprehensive auto-scaling wish list
- Scale out / in based on a schedule (to match usage patterns, e.g. business hours)
- Scale out / in based on performance counters and queue sizes
- Work to my SLAs
- Doesn’t break the bank
- Configuration not done in code
- On heavy load, start cutting back on high CPU tasks / features
- Make optimum use off my billing cycles
- Preferably a host in Azure on a Worker role
- Cover multiple sites with one App
So what are the options to try and achieve this auto-scaling?
- Use a SaaS provider likeAzure Watch
- Build your own
- Leverage on p&p guidance and existing framework – WASABi
WASABi is the Auto-Scaling Application Block and is found in the Microsoft Enterprise Library. MSDN doco is here.
Supports auto-scaling of instances
Proactive and reactive scaling
In Azure worker role
On premise, as a Windows Service or standalone app
Obtain as a NuGet package
Recommendation: Install EntLib Library Configuration Editor
You are then able to configure various rules that determine how your application scales according to need – whether they be time based, demand/usage based or budget based.
Here is an informative video about WASABi:http://channel9.msdn.com/posts/Autoscaling-Windows-Azure-applications
The session also covered TOPAZ – the Transient Fault Handling Application Blockwhich allows you to handle all those transient errors like network or database connectivity issues thatoftengo away quickly but require a re-try to re-attempt an operation. MSDN documentation for TOPAZ is found here:http://msdn.microsoft.com/en-us/library/hh680934(v=pandp.50)
This allows you in code to wrap blocks of logic and apply policies that specify how to deal with failure so that block of code can re-tried. It’s also available as a NuGet package. However this does require you to modify code – for example you should use ReliableSQLConnection instead of SQLConnection for dealing with databases. For pretty much everything else use ExecuteAction method on RetryPolicy.