How to dynamically scale your Windows Azure application in roughly 5-10 minutes

Part One - Introduction

This article is written for IT professionals who are interested in optimizing their Windows Azure cloud applications by dynamically adjusting compute resources to accommodate for changes in demand - in realtime.

The need for dynamic scaling is great: without it, your Azure applications will be performing poorly when demand is unexpectedly high and waste a lot of money when demand is low.  Your application is charged for all allocated compute instances even if they are underutilized or not utilized at all.

There are a number of articles and examples available that allow one to start on the road to creating their own auto-scaling engine for Windows Azure.  The most important thing to know is that you will need to hook into Service Management REST-based API. If you're looking to implement this yourself, I highly recommend reading this article by Neil Mackenzie.  It summarizes all the key information as well as provides links to all known open-source examples and articles on this topic.

However, if your company would rather concentrate on developing its core business products and leave the scaling work to others, whose core competency is dynamic scaling in Azure, then read on.

By following instructions in this article, you will be able to start monitoring and auto-scaling your Windows Azure application in about 5-10 minutes by using the AzureWatch service.  The service is currently free while in public beta and is expected to be released in the very first days of 2011.

Part Two - Installation

At its core, AzureWatch aggregates and analyzes performance metrics and matches these metrics against user-defined rules. When a rule produces a "hit", a scaling action occurs.  This process is distributed across your on-premises computer that is responsible for sending raw metric data to AzureWatch servers, and AzureWatch servers that are responsible for aggregating large amounts of metric data and deciding when your compute instances need to be scaled. The actual scale actions originate from your local computer.

You will need an account to install and use AzureWatch.  Follow this link to fill out a simple registration form.  After registration, download links will be provided.

Part Three - Start Control Panel

After installation is complete, start AzureWatch ControlPanel and login with your newly created account.  You will be presented with a wizard to enter your Azure connection information.

Subscription ID can be found on your Windows Azure developer portal.  If you do not already have the X.509 certificate, AzureWatch can create one for you.  What's important to point out is that AzureWatch needs your X.509 certificate to be located in the LocalSystem\My certificate store.  If you already have a certificate on your computer, chances are that it is located in Personal\My certificate store.  In order to copy it from one store to another, you will need to export your X.509 certificate from Personal\My store into .pfx file and then import it into LocalSystem\My store.  Alternatively, you can choose to create a new certificate that will be installed into LocalSystem\My certificate store automatically, and you will only have to upload it to your Windows Azure account.

Please visit AzureWatch page to understand how your certificates and storage keys are kept secure.

After entering your account SubscriptionID and specifying a valid X.509 certificate, press Connect to Azure.  You will be presented with a list of storage accounts.  Storage account that is monitored by your Diagnostics Monitor is required.

On the next wizard page you can validate default settings for such things as throttle times, notification email, etc.

After the connection wizard is completed, AzureWatch will figure out what services, deployments and roles are present.  For each role found, you will be offered a chance to create simple predefined rules.

The two sample rules offered are simple rules that rely upon calculating a 60-minute average CPU usage across all instances within a Role.  We will come back to these rules in a short while.  For now, wizards need to be completed.

Part Four - First time in Control Panel

After wizards complete, you are presented with a dashboard screen.  It likely contains empty historical charts as no data has yet been collected.  Navigation Explorer on the left shows various parameters that can be customized, while Instructions tab on the right shows context-sensitive instructions.

It is a good idea to visit the the Rules section to see the rules that have been defined by the wizard.  Two sample rules should be present and can be edited by double-clicking on each.  Rule Edit screen is simple yet powerful.  You can specify what formula needs to be evaluated, what happens when the evaluation returns TRUE, and what time of day should evaluation be restricted to.  To make formula entry easier, a list of already defined aggregated metrics is provided.  Hovering over the formula box will display allowed operands.

One last place to visit before starting the monitoring process is the screen that contains safety limits for the number of instances that AzureWatch can scale up to or down to.  By clicking on the appropriate Role name in the navigation explorer, you will be presented with a chance to modify these boundaries.

This is it.  If you are ready, press "Publish Changes" button.  Provided your AzureWatch Monitor service is running, it will pick up these configuration settings in the next iteration of its internal loop and instruct Azure Diagnostics Manager to start capturing the metrics required for formulas to work.  Windows Azure will need a few minutes to instruct your instances to start capturing those metrics afterwards, and then a few minutes more before these metrics will be transferred to your storage.  Thus, give AzureWatch at least 5-10 minutes before expecting to see anything on the Dashboard screen.

Part Five - A few tips and tricks

Some things to keep in mind while using AzureWatch

If you just started using AzureWatch and have not accumulated enough metric data, evaluation of your rules may be suspect as your aggregations will lack sufficient data.  It maybe prudent to disable scaling inside Rules in the beginning so that your scaling actions do not trigger unexpectedly.

Metric transfer occurs only while Monitor service is running.  If you stopped Monitor service for an hour and then restarted it, it does not "go back" and send the missing hour's worth of metrics to AzureWatch.

AzureWatch will always instruct your instances to capture metrics that are defined in the Raw Metrics screen.  You do not need to do anything special with existing or newly started instances.  It may be worthwhile, however, to visit the System Settings screen to further configure how metric enforcement and gathering works.

AzureWatch will send a notification when it scales your instances up or down.  In it, it will provide values for all the aggregated metrics it knows about to help you understand why the scaling event occurred.

Since AzureWatch is a hybrid SaaS, the two Windows components must always be up to date in order to properly connect to the remote service.  Therefore, both of the programs automatically self-update whenever a new version is released.