AZR323A Building Robust Windows Azure Applications

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