Above The Cloud

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.

Just a quick post to inform you about a newly released competition around the Azure Services platform. You can find all the information you need at http://www.newcloudapp.com/

There is a first prize of USD$5000 in both .Net and PHP categories, and a USD$2500 prize for the best community voted application. There’s also additional benefits in the form of exposure and recognition, plus a channel 9 interview.

I would love to enter this competition and prove my Azurish+Developmental prowess, however it seems the competition is only available to US residents. Why? Er, not sure yet. I could guess at something, perhaps to do with how difficult it must be to process all the legals around an international competition. But its not like international competitions are new ground for Microsoft – last year there was a TFS competition, won by a friend of mine here in Australia.

So what’s the deal Microsoft?

The cloud is supposed to be region free. Let’s promote it that way!

According to MSDN, Windows Azure Storage “provides persistent, redundant storage in the cloud”. Microsoft’s goal is to create storage that is durable and secure, scalable and efficient all at once. In the current CTP of Azure you can store your data in Windows Azure 3 different ways:

• Blobs – Large binary data
• Queues – Service Communication abstraction
• Tables – Service state and user data

I’ll aim to dive into each of these in more detail individually over the coming weeks but for the rest of this post will discuss an overview of the storage mechanisms and methods of accessing the storage.

Windows Azure Storage allows you to store data for any length of time and to store any amount of data. Currently there is a lock at 50Gb of storage but for a CTP this should be pretty sufficient. In the future this will scale (at a cost obviously) to as much as you need.

Windows Azure Storage can be geo located, meaning you can choose which region it can be hosted. As previously discussed, you can also associate your data with your Azure services through an ‘Affinity Group’ which helps the Azure Fabric Controller deploy your services and data into a similar place within the data centre. The Azure data-centre’s are so large that having data and services located near each other (network hops) can drastically improve performance (lower communication times).

Its important to ensure you understand that Windows Azure Storage is not the same as SQL Data Services (SDS). If you want a relational data store in the cloud, you should be looking at SDS. Windows Azure Storage is about delivering quick access storage directly to your services, intercommunication between services, and state representation for your application.

Windows Azure Storage is a type of project that you can add in your Azure portal. In the current CTP, you can only add two storage projects. As with adding a service project, you get to select a name that will resolve the services for your storage.

This will result in a set of services to access blob, queue and table storage. You will also be provided with a key that can be used to authenticate you to your storage, allowing you to safely insert, update, and delete data from your applications in a RESTful manner.

Over the next few posts I’ll attempt to break down each of the types of storage, and how to access them through the REST API.

Back at Mix09 there were a number of releases around the Azure Services Platform. One of them was an announcement about the upcoming release of the geo location feature – the ability to choose how your services and data is stored geographically. Well this feature has just reached our hands, being announced on the last day of April on the Windows Azure blog.

I thought I’d give it a spin since I found some spare time today. I created a simple service.svc with a single method and uploaded it to Windows Azure. One of the first things you will notice now during the creation of your project is the option to select your region.

You can be very specific about your location. Currently there are only two locations to choose from with no definite announcements around which locations will come next.

You can also group multiple services/storage projects into a group called an ‘Affinity Group’.

A group is affiliated with a geo location (region). When you create other service or storage projects you can choose any existing affinity group to associate that project with.

Affinity groups are more than just a way of making sure all your services and data are hosted in the same region. They actually provide a way of communicating to the Azure Fabric Controller that services and data are related and should be located near to each other in the data centre for optimal performance. As mentioned in previous posts of mine, the Fabric Controller is already equipped with the ability to provision resources on the fabric in relation to performance, security, and fault tolerance requirements of the user application. Affinity groups are the first step towards providing this control of deployment to the application owner.

As just mentioned there are two locations currently: USA – Northwest and USA – Southwest.

Selecting Northwest first, I uploaded my simple service and performed a name-server lookup:

I also tried a trace route however was unable to get any responses deeper than a router on msn.net. I wrote a quick console application to talk to my cloud service. It calls the service a thousand times sequentially, recording the time taken. In fact I ran this test twice, and the 2 results (in milliseconds) are 717138 and 726795 respectively, the average being about 722 seconds.

Next I ran the same test after creating my project in the southwest region instead. Here’s the lookup:

Interestingly the 2 locations are on the same class B network. This is a little suspicious and I’m interested in hearing from someone in the Azure team as to why this is. I would have thought the range of IPs would be a lot more diverse. I suppose one of the things about minimizing the number of machines required means also minimizing the number of IP addresses needed. Perhaps cloud computing will solve the IP4 empty pool problem?

As before I ran the console application twice and turned up the following two times (in milliseconds) – 767903 and 751676 with the average being about 760 seconds. As you can see this is about 40 seconds slower than when the service was hosted in the Northwest.

As an Australian, I thought I’d run these tests just to see which is the better option. And even though Southwest US is geographically closer to Australia than Northwest US, it would appear that Northwest US is a better choice for your Azure applications if you are targeting Australian users.

While playing around with this new feature I discovered a hiccup. Previously all services were located in one location: USA Northwest. Selecting Southwest for the first time resulted in my production instances not starting up. They simply sat on initializing for an extended amount of time. I stopped and restarted several times and deleted/recreated my project, a few times as well before they finally booted up completely, allowing me to run my tests.

I’m looking forward to similar releases in the future around update and fault domains as we see the full vision of the Azure Fabric come to fruition.