Freigeben über

Case Study: Using Windows Azure to create MicroFinance

  • Artikel

Gary Pretty is the Deputy Head of Programming at Mando Group, a leading digital agency specialising in creating enterprise web sites and RIAs.  Gary works with technologies across the Microsoft stack, including Windows Azure, Sharepoint, ASP.NET and Windows Phone. Gary can be found on twitter @GaryPretty

Using Windows Azure to create MicroFinance

We recently embarked on a proof of concept project to create a line of business web application using some of the latest technologies such as Windows Azure and HTML5 and see if we could combine these technologies with great design to produce an awesome experience for the end user.  You can see the application itself, MicroFinance, at our web site at https://labs.mandogroup.com.

On the road to creating our MicroFinance application, there were some key technical requirements that we were aiming to achieve;

  • The core data behind the application should be consumable on several platforms including Windows Phone.
  • The application should be scalable to be able to cope with hypothetical growth in demands.
  • The application should be reliable and should be available whenever required.

We wanted to see if Windows Azure could help us achieve the above objectives and how easy it would be to work with the Azure platform.

With this in mind we then set about splitting the planned application into several discreet components;

  • The raw data behind the application (i.e. customer details, task lists)
  • The HTML5 web application itself
  • A service to allow the data to be consumed where needed

Now that we had the above separation we needed to decide how each of them could be implemented using the Azure platform.

The Data

For the data behind the application and how it is stored / accessed, we had a couple of options. 

  • The first was SQL Azure, a cloud based implementation of the familiar SQL Server database we all know and love.  Using SQL Azure would allow us to use large data sets and perform heavy data-processing on the data held, as well as being able to define strong relationships between our data entities using out of the box functionality such as SQL joins etc. 

  • Our second option was to use Azure Table Storage, which provides a persistent and durable storage medium, but without many of the features (and complexities) of SQL Azure.

We decided to use Azure Table Storage as in the initial version of the application we are not storing hugely complex or massive amounts of data, meaning we could easily implement Table Storage for our data, perform joins on our data using LINQ once we have retrieved it from storage.  We felt that SQL Azure was overkill for our requirements, but that’s not to say that it isn’t a good solution for many scenarios. 

MSDN Magazine featured an article by Joseph Fultz which provides a detailed comparison of SQL Azure and Table Storage and I would highly recommend you read it if you are facing a similar decision.

The Web Application

The main web application which would be the primary method of accessing and managing the data for the end user needed to be responsive, reliable and scalable.  As well as the core requirements, I wanted to be able to work with the technologies and tools I have always worked with (ASP.NET, C#, Visual Studio etc.).  Happily for me, there is a great Windows Azure SDK Toolkit available with tools for Visual Studio, which makes creating applications and services that run in Azure an absolute snap.

Using the built in project templates that come with the Azure SDK and tools I was quickly able to create an Azure Web Role, used for hosting front end applications behind IIS, within which we could create the web application itself.  From this point, where you have your Azure project created, it becomes business as usual from a development perspective, with the same old familiar ASP.NET pages and techniques you would always use, which meant that it was very easy for us to start writing the application even though it was to be hosted on a different platform than we would normally use.

The big advantage to hosting our application in Azure is the ability to scale at short notice.  Should demand increase, you can simply log into your Management Portal and increase the number of instances of your application that are available to cope with the increased load.  Should the demand drop back again, you can simply reduce the number of instances running back to a more suitable level.  The notion of this rapid and responsive ‘spinning up’ and ‘spinning down’ within Azure is probably my favourite feature and the reason that Azure first grabbed my attention.

The Service

We needed to expose our data to allow it to be consumed by other platforms, as well as our web application.  Initially this was to only be our Windows Phone 7 application (which we will talk about in more detail later in this series), but it is likely that other platforms may wish to access this data in the future. For this reason we decided to implement a WCF service to allow the required flexibility and for our data to be passed out as needed in an efficient manner.  The WCF service was configured to have a couple of different endpoints, allowing us to expose data to both the Windows Phone application, returning our complex data types representing our data (such as customers and tasks) and also as a plain JSON output upon a RESTful request from platforms such as JavaScript.

Testing

From a testing perspective, I only have more good things to say about the SDK and the tools.  There is a set of very capable emulators that work with zero config within Visual Studio.  This allowed us to run the application in a ‘cloud-like’ environment and ensure that the components were working together correctly.  This was especially true with the storage emulator, which allowed testing of our code to create and access Azure Tables.

Deployment

Deployment was my only real niggle with Azure development.  There were a couple of routes available to me to get the solution into Azure.  The first was to package the solution within Visual Studio, which produced two package files, and then to log into the Azure Management Portal and manually setup and upload these packages in order to deploy them.  The second, more favourable option, is an automated deployment from within Visual Studio, however this option is only available to those with top-end Visual Studio editions (Ultimate I believe) and still require some manual configuration within your Management Portal.  Therefore for many people I believe that the deployment procedure could be streamlined considerably.  I also encountered an issue with the configuration of my application which was still configured to use local development storage whilst I was attempting to deploy and therefore causing the operation to fail.  Unfortunately, the error message was incredibly vague and unhelpful, which could be improved.

Summary and What’s Next?

When all is said and done, the experience of developing an application to be hosted within Azure was on the whole a straight-forward and positive experience.  I think that the small issues I encountered when deploying would not be enough to prevent me from recommending Azure to others.

At this point we now had a working core application running in the cloud, with the ability to serve data to a variety of platforms and scale when necessary.  Next we needed to make it useable, look good and just more exciting for the end user in general and this will be discussed in a dedicated series of blog posts on MSDN starting with MicroFinance App, Creating the Front End.