Above The Cloud

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.