Above The Cloud

Straight to the point: if you haven’t signed up for the Mesh beta, go do it now!

So what is Mesh?

Think of Mesh (for now) as a synchronization platform. In Mesh you define folders, and you can sync those folders on 0 or more devices (such as computers, phones, etc). I say “0 or more” because you can just use the web interface if you desire, giving you access to your folders from anywhere.

I don’t want to go into what Mesh is and how to use it, so I’ll refer you to some links:

• Wikipedia Entry – Live Mesh
• Live Services Blog
• Live Mesh Blog

So why am I here?

What I really want to talk about is what’s coming next. You may or may not be aware, but there are in fact two Mesh’ (Mesh’s? Meshes? Mesheses?). Live Mesh Beta is available for anyone to use, however there is also a Live Mesh CTP. The latter is a completely separate Mesh (you cannot share folders across both). This second Mesh represents the ongoing development around Mesh. Users can still get practical usage out of the existing Mesh Beta without risk of the new development effort impacting them.

So what’s different?

Well for starters, access. The Beta is available for all, however you have to apply for a ‘token’ to get access to the CTP (invitations are managed through Microsoft Connect).

Functionally, they work much the same. There is a web desktop, and a client to download locally. Something of interest: the Mesh CTP client is actually called ‘Live Framework Client’. I won’t speculate as to what this might mean going forward (ok a little: the client will be more than just folder sync I’m sure, as we’ll see in a minute). The Mesh is referred to as the Live Framework Sandbox in the CTP version.

The functionality that you are familiar with is the folder sync, the ‘News’, and the ability to remote control to your various devices. In the CTP version, folder sync and remote access is disabled. I’m unsure how long this will last, but for now you can do these things in the Mesh Beta so its not a big concern.

So what’s the point?

This:

Applications! Notice the difference in the top bar from the other screen shot above of Mesh Beta? The ‘Apps’ tab lets you add applications to your Mesh desktop. In this case I’ve added an instance of ‘Corkboard’ and an instance of ‘MeshLists’ to my desktop.

This is what a lot of people have been expecting for a while now. Fully fledged applications running inside Mesh. And the best thing is that its not just constrained to the Web Desktop. When my Live Framework Client syncs, I get an icon on my Vista desktop. This icon is suspiciously named the same as the application I added to my Web desktop.
When I double click it:

The same application is now running on my desktop. And in fact, the same application now runs on my laptop as well, because it also has the Live Framework Client.

If you have access to the Mesh CTP, you may or may not be aware that the latest Azure SDK has a bunch of tutorials around Live Services, including the new Mesh CTP. It demonstrates using Live Delegation Consent to get access to a requesting user’s personal data in Live (such as messenger contacts, Mesh News, etc). Go check it out!

Summary

That’s a brief overview of the Mesh CTP. You should apply for a token now and check it out, then let me know what cool apps you’ve built for it! I can’t wait until they let the folder sync happen so that we can start doing interesting things with our apps around shared data.

This is going to be a very interesting year.

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.