Azure Firestarter Wrap up

Well the Windows Azure Firestarter organized by the Boston Azure User Group has come and gone. It was a very interesting and informative day. I hope the attendees came away with a good feeling for what the Microsoft cloud is and how developers can quickly leverage their .Net skills to program and deploy to the cloud quickly. For the event, I put together a one time application, utilizing Azure technologies.

In short I had an application made up of a Web Role, an Azure Queue, a Worker Role, and SQL Azure. The public facing web site was a Silverlight application, hosted at, which also contained some simple ASP.Net pages, one that received inputs from other applications, and one that served up JSON data for the Silverlight app to consume.

The idea was rather simple, try to make an Azure based web site that would showcase what you could do with a relatively bare-bones Azure architecture, and use it at the Firestarter. In practice, things at the Firestarter got backed up and it wasn’t really showcased, though people did interact with the website programmatically.

Anyhow, it worked like this:

The Web Role had 3 entry points:

  • a simple page, AcceptPings.aspx, expecting particular arguments, together they represented a “ping” to the firestarter system: This was the “web service” that would accept requests and put those arguments on the Azure queue for future processing. The return type was text, and the page only returned “ok” or “failed”
  • a simple page, GetData.aspx, that would return all the pings to the caller as application/json; this was used as a data feed to the Silverlight front end
  • a page hosting a Silverlight application which itself was made up of 4 pages, one of which was a visualizations page and consumed the data provided by the GetData.aspx page

The flow was like this:

  • A user at the firestarter used a sample application to build and deploy a working application to Azure. In that application they would make a call to AcceptPings.aspx with the expected arguments (sample code provided, so user could cut/paste).
  • AcceptPings.aspx would accept the arguments, package them up and put them on an Azure Queue
  • The Worker role would periodically look for messages on the queue and when it found one, it would unpackage it, and store the data in SQL Azure. If a particular argument were present, it indicated that the user wanted to also tweet a message, and this worker role would also hit the Twitter API to tweet the message as a special user, set up just for this event. (using basic auth, which Twitter is disabling very soon)
  • One of the pages in the Silverlight application was a visualizations page, using the Silverlight Toolkit for pie chart functionality, and a grid for simple data display. On a timer (~every 15 seconds), that page would hit GetData.aspx for updated data, and update the pie chart and data grid on the page. This would allow us to see the pie chart and data grid to fill up as users were getting their applications working. If they happened to be following the twitter hashtag we advertised for the event (#bafs), they might also see the new tweets that were going out.

This was a great test app for me to build. It had lots of the components needed for your basic Azure application. Unfortunately, besides being new to Azure, I’m also quite new to Silverlight, the Silverlight Toolkit, and linq, so I took the quickest route  I could to get these working, within the application, the way I wanted to – very plain, basic Silverlight pages, JSON for data transfer (just because I’m so familiar with this), etc.

This entry was posted in Azure. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s