Above The Cloud

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.