Building Highly Scalable Web Applications with Windows Azure

Among many other benefits of moving or building your web applications in cloud, for me I think the most important benefit we get is scalability. When it comes to web applications there are two approaches for scalability.

1. Scale out - This means we increase the number of running instances of the application with a load balancer which distributes the requests among those instances
2. Scale up - This means we increase the physical resources on a single application instance, for example we can increase the RAM of the hosted machine

In reality preferred way of web application scalability should be to scale out. Because there are obvious hardware limitations in scale up approach.

Bearing that in mind if we look at what Windows Azure provides out of the box, for a certain level it supports scale up approach and it has a great amount of support for scale out approach.

Scaling your application out

Windows Azure supports both automatic and manual scale out of the application.

Automatic mode allows you to define a set of parameters/ matrices for your application where Windows Azure will automatically monitor those and spin up additional application instances, the requests for the application will be distributed accordingly with the help of built in load balancer.

If you want this to be done manually it’s also possible with Windows Azure, you can directly do this from right inside Windows Azure management portal. Where you can provision additional instances of your application on the go. 

And there’s the possibility of setting up a schedule as well, if you know the peak hours of your application you can set a schedule and it will automatically spin up required resources to handle the expected load.

Diagram below depicts the high level architecture of a scalable cloud application. You can have your user interaction logics in Azure web roles and time consuming processing tasks in Azure worker roles. In between these two layers communication is seamlessly mediated via Azure service bus, which gives you the ability to scale both web and worker roles without affecting each other. While web roles act as message publishers to the service bus worker roles act as message subscribers of the service bus.

Scaling your application up

Although this is the more conventional approach in application scaling, it’s also supported in Windows Azure. You can increase the resources allocated to your application in 3 different settings, which has preset values for CPU power and memory.

Even though this is much simpler than scale out approach, it has its own limitations. No matter how much you can invest there are physical limitations of CPU power and memory, you will not be able to scale your application beyond that point.

Scaling your database

Windows Azure SQL federations gives you the option to partition the database horizontally this is also known as sharding. If you expect a heavy load on the database the application should be designed in a federation friendly manner from the beginning, in order for you to be able to utilize the features provided with Windows Azure SQL Federations. Else it could be really hard or even impossible to adopt to federations while your application is in a mature state.

Some key concerns in implementing a federated database are

• Most of the times you will not federate all the tables in your database, so the tables which should end up in federations should be selected carefully.
• Not allowed to use Identity columns as primary keys for the tables, viable solutions are to embed ID generation to the application or to use GUIDs as primary keys.
• Inability to run cross federations queries, hence you should be really careful when deciding the federation key 
• Handling database schema changes might get tricky as you will have to update each federation individually
• Data access layer of your application should be designed carefully to support federated database access.
• There could be issues with development environments, because local SQL Server implementations doesn’t support federations. 
• You can use a federated Azure SQL database for development which is shared by your developers
• You can use a different implementation of you data access layer which supports non federated SQL databases.

Despite all these implementation concerns Windows Azure SQL federations significantly improve your ability to scale the database.

Especially if your customers doesn’t like to have their data in a shared database due to security or other concerns, federations provide that much needed physical data separation.

Furthermore a federation can be split on demand to accommodate more data volume, without interrupting your users.

Other than the scalability federations will provide you with high performance and high capacity in the database.

Scalable Windows Azure Cache

Windows Azure Cache service is a distributed cache service where you will be able to build your application in a highly responsive manner while preserving its ability to scale. It comes with a range of features complete isolation of data and super-fast data access.

On premise version

It’s very important to keep in mind that sooner than later you will have customers those are willing to pay that extra premium for an on premise version of your application. So whatever the special things you do in above steps should not bind your applications to the cloud, they should be abstracted in a way that they provide a smooth transition from Cloud to On premise when required. 

Conclusion

So in conclusion we can see that in application level scaling it’s more preferable to go for scale out approach rather than scale in approach. There is an excessive support for scale out in Windows Azure and it hides most of the implementation complexities like load balancing and resource provisioning from the user. 

It’s very important to consider database level scaling with Windows Azure SQL Federations. Although there are few complexities and architectural concerns related to with this, a carefully designed application will be able to utilize Windows Azure SQL Federations when scaling itself.