Over a million developers have joined DZone.

AZR323A Building Robust Windows Azure Applications

DZone's Guide to

AZR323A Building Robust Windows Azure Applications

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.


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. 


Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.


Published at DZone with permission of Rob Sanders, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}