Performance Counters and Scaling

To make the right decisions on scaling up or scaling down your Windows Azure instances you need to have good metrics. One of these metrics can be performance counters like CPU utilization, free memory etc. Performance counters can be added during startup of a worker or webrole or from a distant. Adding a perfcounter within the logic of the role itself is fairly easy.

public override bool OnStart()
{

var config = DiagnosticMonitor.GetDefaultInitialConfiguration();


// Adding CPU performance counters to the default diagnostic configuration
config.PerformanceCounters.DataSources.Add(
new PerformanceCounterConfiguration()
{
CounterSpecifier = @"\Processor(_Total)\% Processor Time",
//do the actual probe every 5 seconds.
SampleRate = TimeSpan.FromSeconds(5)
});

//transfer the gathered perfcount data to my storage account every minute
config.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(1);

// Start the diagnostic monitor with the modified configuration.
// DiagnosticsConnectionString contains my cloudstorageaccount settings
DiagnosticMonitor.Start("DiagnosticsConnectionString", config);
return base.OnStart();
}

From now on this role will gather perfcounters for ever giving you the ability to analyze the data.

How to add a performance counter from a distant?

//Create a new DeploymentDiagnosticManager for a given deployment ID
DeploymentDiagnosticManager ddm = new DeploymentDiagnosticManager(csa, this.PrivateID);

you need a storage account (where your WADPerformanceCounter table is) and the deploymentID of your deployment(multiple instances of a web and/or workerrole is possible since every instance is a running VM eventually).

//Get the role instance diagnostics manager for all instance of the a role
var ridm = ddm.GetRoleInstanceDiagnosticManagersForRole(RoleName);


//Create a performance counter for processor time
PerformanceCounterConfiguration pccCPU = new PerformanceCounterConfiguration();
pccCPU.CounterSpecifier = @"\Processor(_Total)\% Processor Time";
pccCPU.SampleRate = TimeSpan.FromSeconds(5);

//Create a performance counter for available memory
PerformanceCounterConfiguration pccMemory = new PerformanceCounterConfiguration();
pccMemory.CounterSpecifier = @"\Memory\Available Mbytes";
pccMemory.SampleRate = TimeSpan.FromSeconds(5);

//Set the new diagnostic monitor configuration for each instance of the role
foreach (var ridmN in ridm)
{
DiagnosticMonitorConfiguration dmc = ridmN.GetCurrentConfiguration();
//Add the new performance counters to the configuration
dmc.PerformanceCounters.DataSources.Add(pccCPU);
dmc.PerformanceCounters.DataSources.Add(pccMemory);

//Update the configuration
ridmN.SetCurrentConfiguration(dmc);
}

By applying the code above for a certain role (specified by RoleName), every instance of that role is being monitored. Both CPU and memory perf counters are sampled and written to the cloudstorageaccount provided. The data of every 5 seconds per instance is eventually written to storage.

So how make the right decisions on scaling? As you might notice your raw data in storage doesn't help you and only shows sparks. To discover trends or averages you need to apply e.g. smoothing to your data in order to get a readable graph. See the graph below to see the difference.




As you can see the "smoothed" graph is far more readable and shows you exactly how your roleinstance is performing and whether or not it needs to be scaled up/down.

Smoothing algorithms like simple or weighted moving average can help you make better decisions rather than examining the raw data from the WADPerformancecountersTable in your storage account. Implement this smoothing, have it run in a workerrole in the same datacenter and avoid massive bandwidth costs if you examine weeks or even months of performance counter data.

Good luck with it!

Things to consider when migrating to Azure

Migrating existing .NET apps to Windows Azure is usually not much of a problem. It's easy to get it run, it's harder to have it scale. It's about rewriting and re-architecturing your application to fully benefit of the concepts in Azure. Storage (table, blobs, queues), SQL Azure, appfabric etc. Some pitfalls:

- session state: to be scalable store your session data in Table Storage (provider for this is TableStorageSessionProvider and example can be found at ). It's easy, it's scalable and it's cheap and it's always there!
- Separate frontend logic with background tasks and use queues to loosely couple it. Keeps your application scalable and enables you to scale web and worker roles when needed.
- where is my active directory? When moving to Azure and your app is e.g. an intranet application you don't want users to have another login. To tackle this there are two options. First, use Active Directory Federation or second, use the latest Azure Connect. Azure Connect actually enhances your own datacenter by adding Azure nodes to it. Azure Connect makes it easier to migrate because you can setup connectivity between your onpremise stuff and Windows Azure assets.
- from SQL to SQL. Migrating 100% onpremise SQL Server to SQL Azure only needs you to change the connectionstring and make sure you don't use Windows Authentication since Azure won't support it. The more difficult question would be. Do i actually need SQL Azure since it's rather expensive compared to Table or Blob storage. Maybe even a lightweight DB WebEdition will suffice and additional storage possibilities can complement your storage needs.



Part of migrating your application is to change the way you deploy your app (from onpremise to Azure). Using the Windows Service Management API is easy and straightforward and can help you incorporate deploymentlogic into your daily build process. Write your own buildtasks to deploy your app to Staging and have your tests run there, get the results and suspend and delete it again to safe money. Make sure you run your test for factors of an hour since you are charged by the hour.

Patterns & Practices published an excellent PDF around migrating your applications to the cloud.

Will blog some more around migration issues.

A profitable cloud app

In order to be able to have your cloud application or service profitable you need to know what your costs are and what your revenues are. Not only now, but also in the future. When the usage of your app grows you also need to generate more revenue. This can be achieved by charging your customers (or consumers of your service) a fixed price per period or by charging them the same way Microsoft charges you (by use) or a combination of both.

The best way to make sure your solution is profitable is to go with the pay-per-use model. The problem right now is that Microsoft does not offer any realtime metrics (yet). I am sure they will do so in the future but for now you could e.g. apply a multi-tenant approach and bill every customer in a separate way and setup different accounts for every customer. This can work out when the number of customers is small but when your facebook-like application is running and very succesfull this approach is not feasible.

To approach the amount of bytes on bandwith, the storage amount and the computing power used, the # messages on the service bus (maybe even with ACS) is to do it all by yourself. To tackle the number of messages and the storage amount you could write your own logic for it. Calculating bandwith isn't easy and calculating computing power is not even possible i guess.

So until Microsoft offers realtime, dashboard-like information on any customer or groups of customers either charge a fixed price or do you own calculations!

Go to Dallas and pinpoint your needs

Dallas is Microsoft's marketplace where data providers and consumers can meet each other through a simple platform. This platform takes care of billing and makes it easy to subscribe and unsubscribe from datasets. Dallas enables developers to easily integrate rich data from others into their own application or service. Dallas offers owners of rich data an easy way to offer it to a broad audience and increase their revenue or exposure.

Microsoft PinPoint is web platform that enables companies or individuals to find SME's, apps, solutions and services. On the other hand, it enables partners from Microsoft to put them self in the spotlights and show what company they are and what they have to offer. PinPoint is a Microsoft Yellow Pages like directory in which you can browse or search and find the company or solution you need.

As per the 4th of January, 7567 apps, 35953 companies and 13448 Professional services are enlisted on PinPoint. Although the number of "datasets" on PinPoint are as per the 4th of January about 10 available but lots more coming soon. You can see several organizations offer their data for free like AP, Nasa and UNData. You can subscribe on these datasets and use their data in your own application or service. Dallas data can be found through the PinPoint portal and search for application on the Windows Azure Platform but also by using the Dallas portal and choose the catalog tab.

Consuming Dallas datasets is very easy (Microsoft really lowered the bar by defining a standard set of API's) and you just need an invitation code for Dallas. Go the the Dallas homepage and get an invite.

Consume some data
Go the Dallas portal and login with your account. Click Catalog and you should see something like this:



Subscribe on the Associated Press Online Trial Offer. After agreeing the AP Online appears on your subscription tab which opens automatically. You can explore the features of this dataset by clicking the "Click here to explore the dataset". A query screen opens and offers the opportunity to query the data and test the data before integrating it into you application. A very nice feature is the "Download C# service classes" which generates a C# class that wraps the AP dataset and simplifies the access to the dataset (or parts of the dataset). Add this C# file to your application (e.g. a console application) and add the following code to your Main.

using Microsoft.Dallas.Services;

static void Main(string[] args)
{
string accountKey = "***** your accountKey *******";
Guid uniqueUserID = new Guid("**** a userID as a GUID, any GUID****");

Microsoft.Dallas.Services.NewsCategoriesService service =
new NewsCategoriesService(accountKey, uniqueUserID);

List results = service.Invoke();

foreach (NewsCategoriesItem item in results)
{
Console.WriteLine(item.Content);
}
Console.ReadLine();
}

Your output should be like this:



As you can see importing and using data from the Dallas marketplace is fairly easy and that's just how Microsoft wanted it to be. Easy to use and easy to adopt.

This AP dataset is free for now but might be a commercial one in the future. On your Dallas portal at the Access Report tab you can see how many times you've accessed a dataset and see if the billing is adequate.



In the Account Keys tab you can manage account keys and create new ones. What's the use of creating multiple account keys? To differentiate costs to different logical users (can also be entities like departments, companies etc.) for adequate billing if you want to have your customers pay for using your application or service.

Besides consuming data into your application or service you can also use PowerPivot to extend Excel and turn it into your own little data warehouse. PowerPivot enables you to easily consume Dallas datasets but also to import your own data and do some data mining on it. A nice example on PDC2009 was to have the weatherreports from Dallas and combine them with the sales results of an ice cream company and conclude, how shocking, that the sales on chocolate ice radically dropped on a freezing winter day.

As you saw Dallas is a marketplace of data where consumers and producers can meet and easily do business. Dallas data can also be found on the PinPoint portal (and that's how they are related) of Microsoft and therefor Dallas exactly fits in the Microsoft strategy. Consuming data takes no more than 2 lines and use PowerPivot to enhance Excel and turn it into your local data warehouse and perform some nice drill downs.

So far for PinPoint and Dallas.