If you didn’t attend the PDC session The Business of Windows Azure: What you should know about Windows Azure Platform pricing and SLAs I would recommend you to watch it, it really helps to understand the pricing and license model.

Additionally it also helps to understand the value of Cloud computing and being more precisely Azure.

Linked with my previous post Auto-scaling in Azure, I wanted to talk about the most common workload patterns.

On and Off pattern

Growing fast

Unpredictable bursting

Predictable bursting

Identifying your service workload pattern helps you to maximize the compute capacity utilization and reducing TCO.

As I described in the post Auto-scaling in Azure you can dynamically grow or decrease your service compute capacity.So you could schedule the computing capacity of your service according to the workload pattern.

A really complete example has been published on Windows Azure Dynamic Scaling Sample talking about this topic.

If you are still interested on knowing how this requirement can be “manually” implemented,continue reading this post,otherwise I would recommend you to visit the Windows Azure Dynamic Scaling Sample

Combining the strengthens of the Windows Azure Diagnostics API and the Service Management API makes really easy to implement your own logic for auto-scaling your Azure Services.

In this post I will show you how I have implemented a PoC for auto-scaling an Azure Solution and the different options that you have for implementing a similar solution.

1. Solution architecture

The solution components are :

• The Financial service : A WCF service hosted in Azure Web roles.It has two web roles distributed across two upgrade domains for assuring availability.
• The controller Service :  A Controller service hosted in a Azure Worker role.
  • Using the Diagnostics API, it remotely requests the Financial Service to transfer its performance counters to a Azure Table Storage.
  • If it detects a high CPU usage (90% Usage for 3 minutes) Using the Service Management API it will automatically scale the Financial Service.

The following diagram illustrates the solution architecture :

It would also have been possible to host the Controller Service in a traditional on premise service.The following diagram illustrates that option:

2.  Using the Diagnostics API for reading performance counters

With the Diagnostics API you can :

• Dynamically modify the set of counters and traces that your Azure Service will generate.You can modify this configuration from inside your Azure service or remotely (from another Azure Service or from an on premise application).For that purpose you will have to use the class DeploymentDiagnosticManager.

• Request to transfer diagnostic data to Azure Storage,from inside the role that you want to instrument or also remotely (for instance another role or a traditional in-premise service).

The following table outlines the traces and counters that can be activeted and where are stored .

For detailed information about implementing diagnostics in Azure go to the link Implementing Windows Azure Diagnostics

3. Scaling an Azure Service

For scaling an Azure service, you must consume the Service Management API.

Before being able to consume the API, you should generate a self-signed certificate for authenticating the service requests.You can show how this can be achieved in the following link Authenticating Service Management Requests.

After that, you have the following options for consuming the service management API and scaling the service:

• Develop you own API for consuming the REST Upgrade Deployment Service
• Use the Windows Azure Service Management CmdLets

When updating the service configuration,the key it’s to modify the Instances count param of the service configuration.For instance, this XML represents Financial Service configuration contained in the .csfg file

<Role name="GRC.BasicFinancialService">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DiagnosticsConnectionString" value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>

If you want to scale the service using a the power shell cmdlets here you have an example :

string scaleScript="Add-PSSnapin AzureManagementToolsSnapIn "+

"Get-HostedService $serviceName -Certificate $cert -SubscriptionId $subId | "+

"Get-Deployment -Slot Production | " +

"Set-DeploymentConfiguration {$_.RolesConfiguration[$roleName].InstancesCount+=1}" ;

I hope that this post has helped you to see the wide set of options that you have for implementing diagnostics in your Azure Service.

I will upload the PoC I have used as soon as it is fully tested.

Continuing with the last post Update and upgrade domains, I wanted to give more details about the choices in Azure for upgrading a service.

First of all, we can upgrade the service from two places:

• Using the Azure Developer Portal
• Using the Service Management API. The Service Management APIs are a set of REST services that can be consumed from a azure role or from outside Azure.In order to consume the Service Management Services you can develop your own .NET API or use the Azure Service Management CmdLets

Additionally, Windows Azure provides two mechanisms for upgrading your service:

• In-place Upgrade: Windows Azure will stop and upgrade the services contained in each upgrade domain, so if you have distributed your roles in several upgrade domains your service will be responsive in a upgrade process.The following diagram illustrates the process :

You can do Automatic In-Place upgrades to automatically upgrades all domains or Manual for upgrading one domain at one time.

• VIP Swap Upgrade: You can deploy a new version of your service to the staging server, then swap that deployment with the deployment currently in production. This type of upgrade is referred to as a VIP swap (Virtual IP) swap because the address of service running on the staging slot is swapped to the address of the service running in the production slot, and vice versa. See Performing Virtual IP Swap Upgrades for more information.

For more details about the upgrade points, see Upgrading a Service