The Enterprise Library Integration Pack for Windows Azure from the p&p group provides some useful application blocks such as the Transient Fault Handling Application Block and the Windows Azure Scaling Application Block (WASABi).
The Transient Fault Handling Application Block can make access to storage in the cloud more resilient to temporary errors by helping you add retry logic to your code, and WASABi allows you to automatically scale your application in response to changes in demand. Come and hear how you can make your Azure applications more robust by using these application blocks.
Presented by Mahesh Krishnan
Disclaimer: These are conference session notes I compiled during various sessions at Microsoft Tech Ed 2012, September 11-14, 2012. The majority of the content comprises notes taken from the presentation slides accompanied, occasionally, by my own narration. Some of the content may be free hand style. Enjoy… Rob
Follow me on Twitter @ausrob
Introduction
Building applications for the cloud. Resource sharing and economy of scale drives lower cost. Sharing CPU, memory and storage but come at a cost – resource contention et cetera.
How do you design your Azure applications to avoid the contention issues and other factors.
- Auto Scaling
- Patterns and Practices Application Block (WASABi)
- Transient errors
- Basics
- Addressing using TOPAZ Application Block
Cloud Benefits
- Zero or low upfront cost
- Lower on-going cost
- Near-infinite resources
- Elasticity on demand
Scaling – In Brief
- Helps balance running cost with load and performance
- Vertical scaling (increase or decrease VM sizes (memory, CPU (cores), storage)
- Horizontal scaling (increase or decrease instances) – scale out for elasticity
Manual Scaling
- Useful for once-off scaling (but not recommended in most situations)
- Manual scaling can lead to errors/mistakes
Types of Scaling
- Proactive (set up in advance)
- Reactive (respond to demand)
Auto Scaling Wish List
- Built into Azure [not available]
- Scale out/in based on time
- Scale out/in based on perf counters, queue sizes
- Work within SLAs
- Work within budget
- Configuration not hard coded
- On heavy load, cut back on CPU/tasks/features
- Make use of billing cycles
- Host in Azure on a worker role (no need to worry about hosting)
- Cover multiple sites with one app (one role to rule them all)
Options..
- Use a SaaS provider (e.g. Azure Watch)
- Build your own
- Leverage Patterns and Practices guidance and existing framework
- Windows Azure Scaling Application Block (WASABi) part of the Enterprise Library
WASABI in brief
- Supports auto-scaling
- Throttling
- Proactive and reactive scaling
- Hosting:
- In Azure worker role
- On premise, as a Windows Service/standalone app
- Obtain as a NuGet package
- Recommendation: Install EntLib Library Configuration Editor
- Can hand code.. but.. why?
Configuration
- Service Configuration (App/Web.config)
- Additionals – rules, services
- Rules and Service can be stored in BLOBS
Code.to support:
Proactive Scaling
- Uses Constraint Rules
- Time tables
- Budget
- Ranking of rules
- Overrides reactive rules (so.. source of truth for baseline rules)
[Example XML Rule]
Reactive Scaling
- Conditional rules to change instance count
- Can respond to performance counters
- Uses <operands> (performanceCounter, queueLength, instanceCount)
- Instances can take a few minutes to initialize
[Example Reactive Rules]
Throttling
- Use config settings to cut back on features (specifically CPU intensive features)
- Throttling is faster than creating new instances
Stabilization
- Cool down settings
- Allow scale handling (up/down) by time
[Demo WASABi in action]
WASABi settings in the Ent Lib Configuration Editor
Apologies – I have to leave now so I make my Helicopter flight. Mahesh is still demonstrating the WASABi capability for proactive and reactive scaling.
/R
