Above The Cloud

Sometimes I like to look at the types of traffic coming to my site. Somehow I managed to create a blog that gets some high rankings in various Azure searches, and as such a lot of people come to my site looking for answers. The title of this post is one such question that came in quite recently, and I thought it was a great question that deserved an answer (if only I had a way to go back in time to insert this post so that I could answer this person’s question!).

Before we continue, I’ll defer you to one of my earlier posts about what exactly a web role is:

The Web Role is similar to a ‘Web Application’ – it has aspx pages and code behinds, but can also server anything that uses the http protocol, such as a WCF service using basicHttpBinding. The Web Role is driven by UI – the user interacts with a web page or service and this causes some processing to happen.

Web roles can be scaled out by instance count. What this means is that when you create a web role you can have one, two, or thousands of that same web site running at a time. Think of this as having multiple web-heads running the same application.

In a non-Azure world, your Visual Studio solution might look like the left option below, and the equivalent Azure version would look like the option on the right:

A single solution with a single MVC web application serves the products for us to the masses. Of course a real solution would probably have some shared logic in class libraries and probably a unit test project as well, but lets forget about those for now. The Azure version is similar, having the main cloud project, and then a web role for the products website. One instance of our web role will cost us N cents per hour (N is the cost for your country).

Let’s say we also want to provide some B2B integration and create a set of WCF services for our partners to consume. You might add a new project for the WCF end points:

Once again we’ll ignore the other abstractions and unit test projects. We have a services project that hosts a WCF service over http on the left, while on the right we have another web role. Since we need both web roles hosted in Azure, it will cost us 2 times N cents per hour, even if both roles are under utilised.

Do you see the problem here? Traditional layout of our Visual Studio solution will actually cost us more money in Azure! The problem is easily fixed though; minimise your projects (where you can). In our example, this means putting all end points (whether WCF or MVC) into one project, then moving the other related code out into separate ‘code behind’ projects:

In this new design, we only have 1 web role with all the client facing information for the MVC pages (content contains CSS, scripts contains JavaScript and views contains the ASPX pages) and the WCF service (just the SVC file), while the web.config contains information for both components.

The rest of the content such as the controllers and models, as well as the service contract and implementation are hosted in class library projects.

This ensures only 1 web role which means only a base cost per hour. Then if there is heavy load in either the services or the web role, then adding a new instance covers you for both areas.

In this sense, there is no reason to have more than 1 web role in a project.

We’ll think about one more example. Service Oriented Architecture usually lends itself to a solution with multiple projects, where each project is a discrete, autonomous set of services. You might have one project for product information, another for authentication, a third for activity tracking, and another for managing shopping baskets. Each project may have one or more end points, and all the related code and data contracts would be stored in that single project.

In Azure, this would result in four web roles and immediately means a minimum cost of 4 times N per hour, even if those roles are all sitting at less than 10% CPU utilisation. Instead we should move all the service endpoints into a single web role, and then keep the implementation logic separate in discrete class library projects.

So generally, one web role is all you need/want. However there are always going to be situations where it is unavoidable. For example, you might have two web applications with very different forms of authentication.

But for green field projects, please keep the Azure pricing model in mind and try to minimise the number of roles you need, and scale out instances instead when more load needs to be handled.

I’ve recently been working on a little side project – a site called “azure101.com”. I originally created it as a web application project and now decided I wanted to show some friends. I thought about hosting it on a beta sub domain (i.e. beta.azure101.com) but then it occurred to me that I should put it on Azure instead. This meant I needed to create a cloud service project and affiliate my web app with it.

This is a pretty easy thing to achieve if your app stands alone and doesn’t use any databases, etc (which is definitely the case here) so I thought I’d share the few simple steps needed to achieve this.

First you need to add a cloud service project to your solution. In the ‘Add New Project’ dialog, ensure you select the ‘Blank Cloud Service’ option:

This adds the cloud service to your solution – I named mine ‘azure101CloudService’. You will notice only the one project is added to your solution and that the ‘Roles’ node is empty. We need to affiliate our existing web app to the cloud service as a ‘Web Role’. But when we right click the node we don’t get the option to add an existing web project in our solution – its disabled.

This is because the cloud service project does not yet recognize our web application as a valid cloud web role. To fix this we need to make a change to the project file directly.

Editing a project file is not as scary as it sounds. All project files in Visual Studio are built on MSBuild and are friendly looking XML files that follow a specific schema. If you’re familiar with NAnt then you’ll be able to pickup MSBuild in no time, however in our case the change is very simple and you don’t need knowledge of MSBuild to make this change.

First we need to unload our web application project file, and then edit it. I have certain power tools installed that let me unload and edit in one click – “Edit Project File”. If you don’t have this option, simply choose the “Unload” option and then the “Edit” option. It should be pretty obvious where to click. You will notice that when unloaded you will not be able to see any of the files in your project. This is perfectly normal.

In the project file you will see a bunch of XML and we’re looking for a node that’s called ‘PropertyGroup’ (there will be more than 1, just use the first one in the file). This essentially is a list of variables that the build script will use. We are going to add a new variable (property) called ‘RoleType’. As the last element in the PropertyGroup, add this code:

<RoleType>Web</RoleType>

This extra property is what marks a project as being a web role for a cloud service. Save your change and close the file. You can now right click on your web project and reload it. This should restore it to its original state. You can still use the project exactly as before – run it by itself to see what I mean.

Now we can attempt to affiliate the web project with our cloud service. Go back to the Roles node and right click again. This time you can see that the option to add a ‘Web Role Project in solution’ is available. When selected, we then get presented with a dialog where we can choose which project to add – our web application is an option. We select it and when all is done, our web app now appears as a role in our project.

So there you go! Quick and easy. The important thing now is that you can either run the web app standalone, or you can run it on your local development fabric, OR you can deploy it to Windows Azure.

As of the date of this post, when you are working with Windows Azure Services, you get the option to create either a web role or a worker role (or both) for your Cloud Services project. But what are these roles exactly and what do they do?

Well you can think of each role instance as its own project. I tend to liken the two roles to existing Visual Studio project templates.

The Web Role is similar to a ‘Web Application’ – it has aspx pages and code behinds, but can also server anything that uses the http protocol, such as a WCF service using basicHttpBinding. The Web Role is driven by UI – the user interacts with a web page or service and this causes some processing to happen. As far as I can tell, the http pipeline is very similar to standard ASP.NET requests. Just think of it as a good old ASP.NET web application.

The Worker Role is similar to a windows service. It starts up and is running all the time. Instead of a timer, it uses a simple while(true) loop and a sleep statement. When it ‘ticks’ it performs some kind of maintenance work. This is great for background processing.

What the worker is working on is up to you of course, but usually it needs some data to work with. This data can come from a number of places. For example, the AzureServicesKit has examples that show you how to communicate between a worker and a web role via the use of a queue. The idea here is that the worker role doesn’t care how stuff got into the queue: it just does its job of processing items in the queue. It is the web role that is user driven and causes data to go into the queue. The web role can then monitor the queue (via some nicely placed Ajax) and show the results when they have been processed.

So you might think: I’ll always need a web role if I have a worker role. However, this is not true.

Think for a second about Live Mesh. Here you have a folder of all your holiday photos and you’ve modified the actual photos with metadata containing the name of the town or city you took the photo. Live Mesh is built on the same services as the rest of Azure, so communicating between the two is quite easy. You could potentially create a Cloud Service with just a worker role that monitors a particular Live Mesh folder for photos, and when a new one is added, it checks for that metadata with the city name, and inserts latitude/longitude coordinates as additional metadata.

Lets run with that example for a moment. Imagine that the Live Mesh folder is actually a shared folder with thousands of people having access to it (you can do that in Mesh). People are uploading their photos from cities all around the world. Your single worker role can’t keep up with the demand! That’s where Azure steps up: this is what it was truly built for. You can very easily add another instance of your Worker Role. All of a sudden, your processing time is halved!

So there you go. Currently there is a limitation of 2 instances per role. And you can only have one worker role and one web role in your solution at the most. This will seem very restricting once you start to really get into Azure but I suppose there has to be some limitations while Microsoft builds its datacenters around the world.

Steve Marx stated about a month ago (see the comment at the bottom of that link):

… we’re absolutely interested in giving the ability to have multiple worker roles, and multiple web roles, and some other kinds of roles, and direct synchronous communication between them …

He goes on to mention that Microsoft are careful about releasing functionality in a staged manner. I’m predicting that some of the roles we see will more closely match some of the existing projects in Visual Studio, in particular an ‘MVC Web Role’.

Oh before I wrap up, you can also write your worker roles in F# now! Check out the Microsoft site for the download.