Over a million developers have joined DZone.

AZR323A Building Robust Windows Azure Applications

· Mobile Zone


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)


  • 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?


  • 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]



  • Use config settings to cut back on features (specifically CPU intensive features)
  • Throttling is faster than creating new instances


  • 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. 



Published at DZone with permission of Rob Sanders , DZone MVB .

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}