Persisting application data in a web application hosted in the cloud is not as simple as when the application is hosted on a single, on-premise web server. Developing applications in the cloud provides your organization with many important advantages, not the least of which is rapid, on-demand scalability and flexibility. However, as there is no free lunch in this world, these advantages come with a price in terms of needing to adapt your architectural practices to suit this fluid, multi-server environment.
The Windows Azure load balancer will often spread your application across multiple VM’s running on different servers. This nifty bit of magic is almost universally useful, unless your application relies on the use of the Session object. If a user makes a request to your application, there is no guarantee that subsequent requests will be routed to the same server. Imagine a user arrives at your eCommerce website hosted in Windows Azure and adds an item to his shopping cart. He then browses around the site for a while and decides to check out. His “check out” request is routed by the load balancer to a different VM, which was created automatically to handle the load of many users who are also shopping. The new VM says to this user, “Hey, you don’t have anything in your shopping cart.” The user thinks to himself, “I could have sworn I put those items in my cart!” He may have, but those items were stored in a Session object on the first server, by a programmer who didn’t know how to manage state in Windows Azure.
As an Azure developer, there are two primary techniques for managing state. The official method, supported by Microsoft, is using Windows Azure AppFabric Caching. This allows you to provision a cache in your cloud application, which can be rapidly accessed by the various roles in your distributed application. The most common uses are for output caching and, of course, for managing session state. If you only care about usability and convenience, there are almost no downsides to this approach. However, it is the most expensive option. The prices range from $45 per month for 128 MB of caching, up to $325 per month for 4 GB.
A somewhat less convenient, but far more cost effective, approach is to use the Table Storage Session Provider. This is part of the feature set of the Windows Azure ASP.NET Providers library, developed by members of the Windows Azure team. Although developed by the actual Azure team, this library is not officially supported by Microsoft. The Session Provider creates a Session table by default, so developers can use the Session[“key”] = “value” syntax by default, and it will persist across all roles in the application.
This approach preserves the familiar syntax of managing state, and is much lower priced. $0.14 gets you 1 GB of storage, and every 10,000 transactions per month is only $0.01. The downside is that there is some initial setup work to be done, such as changes to the webconfig, and the compiling and integration of the Windows Azure ASP.NET Providers library. In addition, developers will need to manually manage the rows in the storage table to emulate a true session object.
The Session table has a field which holds the time at which the session object stored in that row will expire. As a developer, you must manually check against this field and delete the row yourself when the expiration time occurs. Creation of session objects requires manual creation of table rows, and removal of session objects must be done manually as well.
Regardless of the approach that is best for your application, it is important to keep in mind that the standard ASP.NET state management will not work correctly unless you limit your Azure application to a single role. Doing so negates many of the most attractive advantages of the Azure platform. These techniques will allow you to manage session state in a way that keeps pace with the scalable, robust architecture of Windows Azure applications.