My First Experience with Microsoft Windows Azure

This week I received my Microsoft Windows Azure invitation token, so I began integrating it into a project of mine.  I wanted to use just the Blob Storage to upload and download large media files to the cloud.

At first, I was trying to follow this link as much as possible to get up and running.  The walk-through seemed simple and helped me to quickly understand how to use Blob Storage.  However, once I created the new Azure service in my existing solution I was quickly led to make decisions that influenced the web project I had already created:

1. In order to get the Azure processes to run in the background while my web application ran, I had to set the Cloud Service project as the startup project.
2. A Cloud Service project cannot just run by itselt, it requires a web role.  The simplest thing to do seemed to be to set this to my pre-existing web project.
3. This all worked well at first.  My web project recognized my local azure service and worked normally.  However, once I tried to upload files to my local Blob Storage I received errors.  It behaved as if there was an issue with the Trust Level that the web role runs under.

Since Azure is still in CTP (meaning free) and I have a brand new account (meaning no pre-existing files have been uploaded), my solution was to test my web upload with a deployed, in “production”, Blob Storage service.  I updated my web.config file and fairly quickly was able to upload and download files from blob storage.  I was somewhat impressed with how easy it was to do.

Unfortunately, this created a whole new set of concerns.  Since I am forced to use my production account for Blob Storage, how can I test in my local environment going forward?  Once Azure is launched (reportedly on 02/01/2010), any testing I do will begin to incur significant costs and it will also interfere with production data.

After some deep thinking, some more research and stumbling across this MSDN link, I believe I backed my way into the solution that Microsoft imagined in the first place.

Microsoft has allocated a specific development shared key for local blob storage.  Therefore, one only has to use these standard configuration settings in the local Blob Storage service (ServiceConfiguration.cscfg file).

The piece of the puzzle that I was missing is that this Blob Storage service must run from outside my main solution.  Therefore, I put the Blob Storage service project in its own solution and attached it to a dummy web role.  When I run it, it starts the development Azure services and runs in the background.

Attaching to the Blob Storage service from my web project is easy.  I just make sure that I have the below configuration set in my web.config file.

Now I can test uploads and downloads on my local machine.

Special Note:  The Windows Azure development environment uses a different URI format to access files.  In production, files stored in public containers can be accessed via this format:

http://<account-name&gt;.blob.core.windows.net/<resource-path>

However, in the development environment, a different format is used:

http://<local-machine-address&gt;:<port>/<account-name>/<resource-path>

See this MSDN Article for more information.