|
Architecting a Blog Engine for Windows Azure
|
|
Fri Jan 15th 2010
|
by
Brett
|
|
|
|
|
I have mentioned this in previous articles but this Blog is hosted on Windows Azure. It represented my first foray into Azure development and I thought it might be helpful to point out some architectural changes I had to make when targeting this platform.
Post Storage
Blog posts (the HTML) and comments are stored in a SQL Database (along with Role and Membership Services). Created a SQL database was pretty straightforward in Azure, but unfortunately none of the SQL 2008 management tools work against Azure. This created some difficulties at first because additionally some aspects of TSQL are not supported in Azure. Fortunately a tool exists that lets you take existing databases and script them to SQL Azure (including data if desired). It will also parse SQL files and remove any non-supported TSQL so you can run them directly against Azure. It can be downloaded here:
http://sqlazuremw.codeplex.com/
I also had to grab a custom script for setting up the ASP.NET tables which can be found here:
http://support.microsoft.com/default.aspx/kb/2006191
I have a very common architecture that looks like this:
Fig 1. Architecture Diagram
As mentioned in another post, make sure you decorate your services with the following attribute or you may run into trouble when trying to access your service when published to the cloud.
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
Technically the JSON service and Silverlight service could have the same code and just be exposed as different endpoints, however I have found when working with jquery and JSON that you often want to simplify your object graphs both for performance and ease of coding on the client side. Not only that, but rarely is there a 1:1 overlap between the two services.
All my server code is hosted in a single Azure WebRole. I could have hosted the services in WebServiceRoles but in a simplistic case like mine I didn't see the benefit.
Post Media Storage
I have a slick little file uploader I wrote for Silverlight 4 that lets me drag and drop files onto it, which are in-turn uploaded to my site. Content usually includes images, but can also be source code or XAP files when demonstrating Silverlight. The Silverlight piece is backended by an ashx file that accepts the upload stream and writes the file to disk.
Normally – I create a directory structure to host these files beneath the website (being careful to setup IIS so that files in this directory cannot be executed). This actually works fine in Azure, however a subtlety of the Azure architecture prevented this from being a valid solution. Each time you publish, or update your Azure project anything previously in the file-system is wiped out. This means that if you were relying on the file-system for storage those files are now gone.
I considered storing the files in SQL directly, but that has never been my favorite approach for a lot of reasons. Back in the old days it was ill-advised because of performance reasons, however I don’t believe that to be the case any longer (SharePoint stores all of its content there and it scales very well). It is still however a fair share of work to setup the code to write and extract the data. You also have to consider setting up an HTTP handler to stream the files out, which includes setting the proper content type.
All that considered it seemed to me that Azure Storage would be a good candidate. It has a REST service that lets you post/retrieve items, and individual items are URL addressable, eliminating the need to write my own handlers. Of course not knowing a things about working with Azure blobs I realized that I would spend way for time learning and troubleshooting this new tech than the four hours it would have taken me to implement the SQL solution :> Of course I opted for the sparkling new toy.
Handily classes exist in the Azure assemblies that wrap the REST calls. This is a big timesaver and a lot less error prone when compared with making the REST calls yourself. I did get stuck a number of times and will document what I learned in another post as I want to keep the focus of this article on architecture not code.
After learning the ropes and completing my implementation Azure Blog Storage worked great. It even lets you do some neat things with metadata so that you could organize your content around the associated Articles. (I haven’t done this yet, but plan to) In my case I created a Container (almost akin to a drive) and stored all my files there. Containers may contain directories as well, however I didn’t make use of that feature.
|
|
|
0 Comments
Login to post comments
|
|
|
|