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. Set As 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).

<ConfigurationSettings>
<Setting name=”AccountName” value=”devstoreaccount1″ />
<Setting name=”AccountSharedKey” value=”Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==” />
<Setting name=”BlobStorageEndpoint” value=”http://127.0.0.1:10000/&#8221; />
</ConfigurationSettings>

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.

<configuration>
<appSettings>
<add key = “AccountName” value=”devstoreaccount1″/>
<add key = “AccountSharedKey” value=”Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==”/>
<add key=”BlobStorageEndpoint” value=”http://127.0.0.1:10000″/&gt;
</appSettings>
<configuration>

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.