The previous articles covered the basics you need to understand and build your own Cloud Service. In this part we’re getting closer to deploying our Cloud Service to production. We’ll see how you can debug your application both locally and in the cloud, as well as take a look at what you’ll typically do when your application is running in production: monitoring and scaling.


The first stage in the development process is testing everything locally. The Azure SDK comes with Visual Studio integration and an emulator to support local development. When you open the properties of your Cloud Service project in Visual Studio you’ll be able to configure how the emulator runs when you press “F5” in Visual Studio.

The first choice you can make is which type of web server you want to run when you’re working with Web Roles. The default value here is IIS Express. This is a light weight, self-contained alternative to IIS which is especially useful when you don’t have IIS installed on your machine or when you’re not a local administrator on your machine. The alternative is using a normal IIS Web Server which comes closer to how your application will be running when deployed to a Cloud Service.

The second choice you can make is the type of emulator you want to run. The Full Emulator requires Visual Studio to be started as an administrator while the Emulator Express does not require this. The other big differences are that the Emulator Express cannot use the IIS Web Server and each role is limited to just one instance.


Figure 1: Configuring the Emulator

When running the Cloud Service from within Visual Studio a tray icon will appear for the Emulator and you’ll be able to visualize your roles and instances by opening the Compute Emulator.


Figure 2: Emulator Instances

In addition to that you can also use a Storage Emulator which emulates an Azure Storage account on your local machine by using SQL Express or Local DB. Because of the differences between the Storage Emulator and an actual Azure Storage Account it’s important to evaluate its usage in your project and possibly choose to use a real Storage Account even for development purposes. If you do choose to use a live account it should be a different storage account than the one you’re using in production.


An issue you’ll probably run into at some point when deploying your Cloud Service is that the role instance is Cycling which means that the instance keeps restarting in a loop during the deployment. These issues can be hard to troubleshoot and are often related to files that are missing in the Service Package. The main reason why this is so hard is due to the fact that your application hasn’t really started yet, so most of the time there aren’t any detailed logs available to help you troubleshoot the issue.


Figure 3: Role Recycling

This is why IntelliTrace (which is part of Visual Studio 2013 Ultimate) can be an interesting feature to activate during the deployment of your Cloud Service. When your instance starts IntelliTrace will record every single detail of what your application is doing: file access, registry access, network access, every line of code being executed, etc.


Figure 4: Enable IntelliTrace

Using the Server Explorer in Visual Studio you can then browser to the instance that’s having issues and view the IntelliTrace logs. This will download the “recording” and will allow you to analyse it locally in your Visual Studio.


Figure 5: View IntelliTrace

The IntellTrace Summary will be your first stop when troubleshooting issues with instances that have problems starting up. You can then select one of the recorded exceptions and double click it to attach the debugger.


Figure 6: Intellitrace Summary

The debugger will attach itself to the recording and using the IntelliTrace pane you’ll be able to navigate through every recorded event that can contain a lot of detailed information. In case you’re doing a call to your database, you’ll see the full statement being executed for example.

Figure 7 shows troubleshooting an issue with a missing assembly in the Service Package. For this deployment the Fabrikam.Todos.Helpers assembly was missing from the deployment. The reference wasn’t set to Copy Local = true in the reference’s properties.


Figure 7: Intellitrace Drill down

Note that enabling IntelliTrace will consume a lot of resources in your instances. In a dev/test environment this shouldn’t be a problem, but as soon as your application is moving to production make sure you disable the option to avoid any performance issues.


Remote Debugging

The Compute Emulator is already a great help when it comes to developing and debugging applications locally. But there will be times where you’ll need to debug an application which is running in Azure. This can be when your application is under a high load, when you want to analyse a problem that is only happening in production, or you have an edge case that is hard to reproduce locally.

This is where the Remote Debugger comes in. When you deploy your Cloud Service from Visual Studio you can also enable the Remote Debugger for your roles.


Figure 8: Enable Remote Debugger

The Remote Debugger will allow you to attach the debugger to an instance running in the Cloud.


Figure 9: Attach Debugger

Figure 10 shows the process chooser you’ll see once the debugger is ready to be attached. For Web Roles you’ll want to attach to WaIISHost.exe and w3wp.exe, and for Worker Roles you’ll be using the WaWorkerHost.exe process.


Figure 10: Choose Process

An issue you might run into is that even if you’ve set some breakpoint they never get hit. If this happens this typically means that the symbols for your application and any libraries you’re using have not been loaded.

To load the symbols you’ll need to open the Modules window in Visual Studio (Debug, Windows, Modules) and choose to load the modules for any assembly you want to debug.


Figure 11: Load Symbols

Once everything has been configured you’ll see that you’ll be able to debug everything happening in your instance in real time.


Figure 12: Breakpoint

Note that setting this breakpoint will block the execution of other requests on this instance. That’s why it’s best not to use the Remote Debugger in production. If you still need to test the behaviour with a production instance you can always swap the application to a staging slot and troubleshoot from there (to avoid any impact for your users).


Scale and Manage

Your application is now running in the cloud without any issues. It’s important that you keep it like this and that your application runs in the best circumstances. This is why scaling and managing of your Cloud Service becomes important once your application is running in production.

In “Part 1: Introduction” we’ve seen how easy it is to scale a role by just moving a slider up or down and hitting the Save button. This is the easiest but also the less automated way to scale your Cloud Service.


Figure 13: Manually changing the number of instances

Typically you’ll want to scale when something happens: the site is very slow, it takes a long time before orders are being processed, etc. This is where we’ll move to a more automated way of scaling your Cloud Service.

The dashboard allows you to configure Auto Scaling for your roles. One of the metrics that can be used for auto scaling is the queue size of your Azure Storage Queue. Figure 14 shows a possible scenario where we want to have no less than 1 instance and no more than 8 instances in our Web Role. The target number of messages in queue “commands-webrole” is 2000. As soon as we exceed (2000 * the number of machines) in a given storage queue more instances will be added to the Role until the maximum (8) is reached. When the number drops below 2000 messages the auto scale engine will start removing instances. In both cases every time instances are added or removed there will be a pause of 20 minutes between operations to avoid instances from being added or removed all the time.


Figure 14: Scale based on queue size

Another metric that can be used is the CPU of your instances. Figure 15 shows a similar setup as the previous one. The only difference is that instances will be added when the total CPU usage for this Role exceeds 80% and instances will be removed when the total CPU usage drops below 60%.


Figure 15: Scale based on CPU

Keep in account that adding instances can take a few minutes, so in case your application is experience a peak make sure your application is resilient enough to overcome this load until the new instances are available. Autoscaling can be particularly useful if you know that traffic has a definite pattern on your site as you can schedule a scale out before the peak moment occurs.

For more automated ways of managing your resources there are other tools available like the PowerShell cmdlets or the azure-cli (a command line tool which can also run on Mac/Linux).


Figure 16: Manage using the CLI

All of these tools talk to the Service Management API which exposes almost everything you can do in the Azure Portal. On NuGet you can find official .NET clients that make it easy to interact with the Service Management API. Figure 17 shows how to scale the role to 4 instances using just a few lines of code.

Figure 17: Service Management Libraries

Another important part of properly running your application is having a good view of everything that’s happening in your Cloud Service. This can go from performance to different types of logging (Event Log, your application logs, etc.).

Michael Collier covers many of these concepts in great detail in the Microsoft Azure Diagnostics series.

But it’s still worth covering a few of the basics and go over a feature that will make it really easy to have your own logs or third-party logs (eg: ASP.NET, WCF) end up in one of your storage accounts.

The release of Azure Diagnostics 1.3 changed a few important things in terms of diagnostics configuration. Before version 1.3 you roles needed to embed the Diagnostics module in the deployment and you were able to define your diagnostics configuration in code (eg: when the Web or Worker Role instance started) or using a *.wadcfg file.

With Azure Diagnostics 1.3 we’re no longer embedding a Diagnostics module in the Service Package but we’re enabling a diagnostics extension for the Cloud Service slot (Production/Staging) from within Visual Studio or using PowerShell.

A new feature here is also the support for ETW (Event Tracing for Windows). This brings support for high performance, semantic logging to Cloud Services.

Figure 18 shows an example of an EventSource class you would write to start using ETW. The Event Source will have a name and one or more methods that represent the events that can be logged. You can optionally define them with parameters if you need to log additional primitive values together with the name of the event.

To learn more about ETW traces you can look at the Enterprise Library Semantic Logging application block.

Figure 18: Event Source

Then from within your instance you can call these events which will then cause the event to be broadcasted. Your application isn’t writing this to file or to Table Storage, the event is just made available to any process out there that is listening to it. This is what makes it really interesting in terms of performance because the impact here is zero, your application is not responsible for persisting these logs.

Figure 19: Logging Example

When you’re interested to gather the logs for all of your instances to a single place you can configure the diagnostics for a Role in a given slot (Production/Staging).


Figure 20: Update Diagnostics

Visual Studio allows you to configure where to pick up application logs, whether to enable transfer of Windows Event logs, performance counters, etc.


But more important in this scenario is that we can configure which Event Sources should be persisted to your storage account. Figure 21 shows how we’ve configured the output of event source Fabrikam-WebRole (from Figure 18) to be transferred to your storage account every minute.


Figure 21: Configure Event Source

Every action being logged in this event source will be persisted in a Table in your Azure Storage Account (which can be configured on the General tab).


Figure 22: Table containing the logs

Figure 23 finally shows the logs which have been persisted in this dedicated table. Every record includes essential information like the moment when it happened, the instance name, the name of the event, deployment ID and more.


Figure 23: Logs

We can now deploy our application to production with confidence. The next part will cover the options for deploying your application and also discuss how to avoid downtimes when doing so. See you soon!