Showing posts with label wasabi. Show all posts
Showing posts with label wasabi. Show all posts

Reading Notes #60

[…]Read this getting started tutorial to walkthrough how you can build (in less than 5 minutes) a simple Windows 8 “Todo List” app that is cloud enabled using Windows Azure Mobile Services. Or watch this video of me showing how to do it step by step. […]

[…] 9% of all men are color blind. Use to check how your site or web app looks to those people. […]


Azure Tools Belt: Auto-scaling Application Block – WASABi

One of the questions that clients often ask is: What tools could be used for Windows Azure development. Everyone knows that you need a web browser and a code editor (ex: Visual Studio), but what else? So, I decided to do a serie of posts to present them. This second post is about the Auto-scaling Application Block or WASABi for friends.

This serie is not meant to be an exhaustive list of all tools. Some other excellent tools are surely available. If you think I have forgotten one or want me to talk about one, let me know. I will be more than happy to adding it to the list.

Already in the Azure Tool Belt:

What is WASABi?

To achieve elasticity until now, you needed to do it manually through the Azure management portal or writing your own code using the REST API. Using Wasabi, you just need to define some rules and the application will scale automatically: It can use a schedule or can be triggered by metrics, for example running fewer instances at night or adding extra instances if the CPUs are used at more than 80%.

The auto-scaling application block can be hosted either in a Windows Azure role or in an on-premises application. The auto-scaling application is typically hosted in a separate application from the target application that you want to scale.

Various scenarios are available to help you manage the auto-scaling by dynamically changing instance counts or performing application throttling of web/worker roles. The rules can auto scale based on timetables or metrics collected from the application and/or Windows Azure. You can even use notifications to preview any scaling operations before they take place and you can also use some PowerShell cmdlets to manage the autoscaler. You can constrain the auto scaling by:
  • Setting the instance counts upper and lower bounds
  • Preventing fast oscillations in the number of role instances with the stabilizer
  • Limiting scaling operations acknowledging billing hours

How to use it

For this demo we will use a simple Hello word application and scale it with a rule via a console application based on time.

Step 1: Put the app in Azure

clip_image001[4]To get started an Azure application is needed. Don’t forget to assign a certificate since the console application will need it.

You can then publish the application on the cloud.

Step 2: Adding the scaling application

clip_image002[4]Now create a console application and name it AutoScalingConsole. Add the WASABi package by executing: Install-Package EnterpriseLibrary.WindowsAzure.Autoscaling.
It should run without error and your Solution should look like this.

Step 3: Add and configure the rules

Add a new file call Rules.xml and set the property Copy to Output Directory: Copy always. Copy-paste this xml into the rules file.
<?xml version="1.0" encoding="utf-8" ?>
<rules xmlns="">
    <rule name="default" enabled="true" rank="1" description="The default constraint rule">
        <range min="1" max="1" target="AutoscalingApplicationRole"/>
    <rule name="peaktime" enabled="true" rank="10" description="Increase instance count at peak times">
      <timetable startTime="20:00:00"  duration="00:20:00" />
        <range min="2" max="4" target="AutoscalingApplicationRole"/>

It contains two rules: A default one that is always active, defining minimum and maximum instance counts of 1, and a second one used for scaling. The variable “Is rank” with a value of one means that it can be overridden by other constraint rules with a higher rank. . Naturally, if that rule is applied, there will be only a single instance of the role.

The second rule is named peaktime. This rule has the same target, a higher rank, a minimum value of two, a maximum value of four. Also a timetable makes the rule active for 20 minutes, starting at 10 minutes from the current time.

Step 4: Define the service model

You will now add a new xml file called services.xml and set the property Copy to Output Directory: Copy always. Copy-paste this xml into the services file.
<?xml version="1.0" encoding="utf-8" ?>
<serviceModel xmlns="">

    <subscription name="[yoursubscriptionname]"
                  certificateStoreLocation="CurrentUser" certificateStoreName="My">
        <service dnsPrefix="[yourhostedservicednsprefix]" slot="Staging">
            <role alias="AutoscalingApplicationRole" roleName="AutoscalingApplicationRole" wadStorageAccountName="elazurehol"/>
        <storageAccount alias="elazurehol"

In this file, make the following changes:

Replace [yoursubscriptionname] with the name of your Windows Azure subscription and [yoursubscriptionid] with your Windows Azure subscription ID.

Replace [yourmanagementcertificatethumbprint] with your Windows Azure management certificate thumbprint.

Replace [yourhostedservicednsprefix] with the URL prefix of your Windows Azure hosted service.

Replace [yourstorageaccountname] with your Windows Azure storage account name and [yourstorageaccountkey] with your Windows Azure storage account primary access key.

Step 5: Configure the Auto-scaling Application Block

Right-click on the App.config file in Solution Explorer, add one if needed, then click Edit Configuration File. In the Blocks menu, click Add Autoscaling Settings. Now set the rules.xml and services.xml as sources for Rules Store and Service Information Store. Via the File menu, Save then Exit.


To by able to track evolution of the the testing let’s add some logging.  In Visual Studio, double-click on the App.config file to open it in the editor. Then add this system.diagnostics at the end of the file:
      <source name="Autoscaling General"  switchName="SourceSwitch" switchType="System.Diagnostics.SourceSwitch" />
      <source name="Autoscaling Updates"  switchName="SourceSwitch" switchType="System.Diagnostics.SourceSwitch" />
      <add name="SourceSwitch" value="Verbose, Information, Warning, Error, Critical" />

Step 6: Try it

You can now run the console application and observe how the auto-scaling rules work with the Azure application. Check the Output window in Visual Studio that logs which rules are being matched.


Using Wasabi makes your application elastic but doesn’t make your application scalable you must therefore design for scalability. If you have any comments, suggestions or experiences to share, feel free to let me know by adding a comment, by e-mail or by the contact page.

Where to find More info?



Reading Notes #45


Azure lets us focus on our product rather than focusing on how we need to scale the application
“For a rich comparison of SQL Azure and Windows Azure Table storage, see Joseph Fultz’s MSDN Magazine article at:”
This blog has three posts that give detailed explanation of how a test rig with Controller and Agents can be created in Windows Azure.”
There does not seem to be any good working OAUTH v2 examples for Java using ACS




Reading Notes #44

They Will Bring You In The Cloud
They will bring you in the cloud.



  • Code First model builder versions (Arthur Vickers) - This post explain how to configure EF code first to avoid any breaking code when updating the framework to a newer version. Nice work.
  • Créer son propre Gem et le publier - Very nice tutorial (in French) that explain in detail with a simple case how to create and also publish a Ruby Gem.


  • 5 Tricks for a Killer Company Blog - Five simple tips to get started blogging in a business perspective.
  • Hit the Presentation Sweet Spot - Twenty minutes is very short. Maybe it is a good idea for a specific type of presentation... How do you plan a 2-3 formation?
  • Your Personal Brand as a Developer: Implementing (Part 2 of 2) (Jonathan Rozenblit) - Part 2 on an unusual topic but important. Our brand, as a person. On the internet everything is amplified and could be seen by a lot of people very quickly. A post to read "before it is too late".
  • Coping with Email Overload (Peter) - This could be a good advice for a lot of people. While I'm working on a project where co-workers are across the country I not sure I can do this but maybe tweaking it with rules for only those people.

Reading Notes #40




      ~ Frank