Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Autoscaling Windows Azure applications

56 minutes, 56 seconds


Right click “Save as…”

The ability to rapidly scale your application in response to changes in demand is one of the key benefits that Windows Azure delivers when you host your applications in the cloud. 

If you rely on manual interventions to scale your application, you may not always achieve the optimal balance between costs and performance. An autoscaling solution reduces the amount of manual work involved in scaling an application dynamically.  In this video, we demo how this can be accomplished with WASABi (the Windows Azure Application Block) in two different ways: either by preemptively adjusting the number of role instances based on a timetable, or reactively by adjusting the number of role instances in response to some metric that you can collect from your application or Windows Azure environment.

The first WASABi preview is available via NuGet (just search for 'wasabi' from the NuGet Package Manager within Microsoft Visual Studio).

We provide an overview of WASABi scenarios and the block's architecture. If you want to jump straight to the demo, skip to 15:43.

For more information, see


Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • What I see in management protal doesnt actually make sense. When scale up or down is happening, it seems that all instances are updating. I expect that the working instances keep working when scale up is happening.

  • Duncan MackenzieDuncanma "yeah that's awful close, but that's not why I'm so hard done by"

    @Meisam: When you go into the configuration and change the # of instances, all of the currently running instances will appear to update because they are all receiving an event indicating that the configuration has changed. If you handle that event, make sure to set Cancel to false to indicate that you do *not* want the role to restart.



  • MithyaMithya

    Thanks for the video. It is helpful. A few questions:

    1) What is alias attribute? Video has name attribute but I believe it is replaced by alias? Does it connect rules?

    <service ...>
    <role roleName="ScalingHelloWorld" wadStorageAccountName="wadStorageAccount" alias="1">
    </role> </roles> </service> </services>

    <storageAccount connectionString="UseDevelopmentStorage=true" alias="1"> </storageAccount>

    2) What about certificates? Do we have to add any additional certificates to make this work other than two that we add on Management portal and under hosted service?

  • MithyaMithya

    From this example and Tailspin on MSDN, I get feeling that the autoscaling host should be different from the target. Is this the case? Can I have a worker role host which references WASABi library and applies scaling rules on itself to autoscale itself?

  • @Mithya,

    Sorry, I didn't get notifications about your questions and only saw them today.

    1) Yes, in the final version this attribute is called "alias".

    2) You need to make the management ceriticate available to the role hosting Wasabi. This means deploying it through the Windows Azure portal and adding it to the list of certificates for the role. Then you also have to specify that certificate's thumbprint for the subscription element in the services store.

    3) You can have Wasabi autoscale itself (the block is prepared to deal with multiple instances of the autoscaler - we are using an execution lease), but that's not necessarily something that you would probably want to do. The technical reason is that it's better for an autoscaler to be running continuously in an instance. If you modify your app and decide to redeploy, the autoscaler will need to be interrupted and redeployed as well. Thus, it's better to run in its own role - an extra small worker or web role would do.



Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.