Autoscaling Windows Azure applications

Download this episode

Download Video

Description

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

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • Meisam

      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.

    • Duncanma

      @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.

      http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k(MICROSOFT.WINDOWSAZURE.SERVICERUNTIME.ROLEENVIRONMENT.CHANGING);k(TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22);k(DevLang-CSHARP)&rd=true">http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k(MICROSOFT.WINDOWSAZURE.SERVICERUNTIME.ROLEENVIRONMENT.CHANGING);k(TargetFrameworkMoniker-%22.NETFRAMEWORK%2cVERSION%3dV4.0%22);k(DevLang-CSHARP)&rd=true

       

    • Mithya

      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 ...>
      <roles>
      <role roleName="ScalingHelloWorld" wadStorageAccountName="wadStorageAccount" alias="1">
      </role> </roles> </service> </services>

      <storageAccounts>
      <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?

    • Mithya

      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?

    • melnik

      @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.

       

       

    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.