Mobile Zone is brought to you in partnership with:

Rob is a professional IT specialist with over 14 years of commercial expertise working for small, medium and large enterprise customers and clients as well as local, state and federal governments within Australia and internationally. Of these fourteen years, six have been served in a professional consultancy capacity, three as a project manager and eleven years in professional software engineering and architecture. Rob is a DZone MVB and is not an employee of DZone and has posted 57 posts at DZone. You can read more from them at their website. View Full User Profile

AZR323A Building Robust Windows Azure Applications

09.13.2012
| 2473 views |
  • submit to reddit

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:

IMG_2223

Proactive Scaling

  • Uses Constraint Rules
    • Time tables
    • Budget
    • Ranking of rules
  • Overrides reactive rules (so.. source of truth for baseline rules)

[Example XML Rule]

IMG_2225 

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]

IMG_2226

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]

IMG_2227
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

Published at DZone with permission of Rob Sanders, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)