Stateless in Seattle (Windows Azure series)
After a longer delay, I’m bringing you the next post to in the series about the Windows Azure platform here on DevNet. This time we will discuss statelessness in Windows Azure. This is the most basic requirement for your application to be able to run there. I will explain the challeneges related to this topic in details and describe how you can solve them.
Let me start with the fundamental basics. You surely know that the World Wide Web is powered by the HTTP protocol. This protocol works based on request-response behavior. There is no state mechanism behind that – the server answers without any information about the previous request/s, so HTTP follows completely stateless pattern
. That’s fine for simple pages. But what if you have a more sophisticated web application? A great example of this can be simple user authentication. A User user first inserts his credentials on one page, then continues with browsing and every single page has to know that the user is authenticated. In a scenario like that, the application needs to remember the state.
There are lots of mechanisms used to store state. We have cookies
and query strings
. With ASP.NET there is also view state
, control state
and application state
. You can also build your own state mechanism. The thing is that with all this stuff, web applications became stateful by their very nature.
Now let’s examine what it means to be a stateless web application for Windows Azure. You can use these state mechanisms but their storage must be independent on where the application is running. In Windows Azure you typically run your application on multiple machines. Machines are started and turned down according to the current administration needs. Request flow is controlled by the load balancer. The picture bellow shows this scenario.
It is also important to understand how the load balancer works. In Windows Azure, according to an answer from the dev team responsible for Windows Azure networking, the algorithm is pure round robin
. This means that every request goes to a different machine (instance) and it doesn’t matter how busy the given machine is busy or who sent the request.
And that’s the reason for what is written above – you cannot store state data on a specific Windows Azure instance – it has to be stored independently. Fortunately, many of state mechanisms aren’t stored on the server – you only need to take care of the session. You may think that there could be another problem – view state. View state is by default encoded based on the machine key, but you can set up the machine key in the web.config file and every new instance will use it. Another option is to leave this completely on Windows Azure. There is a mechanism for inserting the same machine key for all your instances.
Session state provider
Let’s go back to the session. In ASP.NET you have three standard session state providers:
InProc – Stores session state data in the process memory – it can only be used on Windows Azure only in a single instance scenario.
StateServer – Stores data on a specific server - also unusable because it needs one certain particular server to store session state data. And if you for example change the number of instances, you cannot choose which instances will be shut downed.
SQL server – You can use MSSQL in Windows Azure thanks to the Windows Azure connect feature. But there are several problems with this solution. It’s definitely overkill to have an SQL server only to save session state data. It’s quite an expensive solution and also you need to be aware of the connection delay between your SQL server and Azure instances.
None of them simply fits into Windows Azure. However there are special session state providers for Windows Azure:
SQL Azure provider - Microsoft officially doesn’t support a session state provider for SQL Azure, but you can download scripts for creating tables in SQL Azure from their team blog. SQL Azure doesn’t have an agent used to delete old sessions, so you would need to create your own mechanism for deleting them.
Table/blob provider – Windows Azure samples contain a session state provider which stores data into tables and blobs. You register this session provider as a custom provider in the web.config file and you need to add one library to your project. The disadvantage of this solution is missing support from MS (in case of a bug in this sample library, you are on your own) and also an unpredictable price.
Windows Azure Appfabric cache provider – Appfabric cache contains a provider for storing session state data in the cache. It is easy for to use, you just register the Appfabric cache in the web.config and add references to Appfabric libraries (see this page for details). This provider is tested and recommended for use with Kentico CMS 6.0. Our web.config file in version 6.0 will contain registration sections so you just add your own authentication token and you will be able to use it.
Synchronization of cached objects
Synchronization of memory cached objects could be also be a problem in a multiple machines environment like Windows Azure. For example, in Kentico CMS, are css stylesheets are stored in hash tables because loading them from the memory is way too faster than getting them from the database. But if you run your app on two instances and you edit a css style sheet on one server, the second server needs to be informed somehow that the data is changed. Kentico CMS has a module called Web farms for this purpose. It creates a task every time something in a cached object is changed and informs other servers to that they should update their cache. We improved this module especially for Windows Azure. When a new instance is started, a web farm server is created for it and everything is set up automatically.
Another possibility is to use Windows Azure Appfabric cache. This product is build built based on Windows server Appfabric and it uses the same API. There are some limitations in the Azure version – for example callbacks aren’t supported yet.
And what about using Windows Azure Appfabric with Kentico CMS? It will be possible with 6.0 version 6.0. Our CacheHelper class will be customizable, so you will be able to write your own implementation and store data in the Windows Azure Appfabric cache. But since Appfabric cache doesn’t support cache dependencies (this is the case for both Windows server and Windows Azure), you will be limited to using cache timeouts.
This is all for today, I hope this post was useful for you. In my next blog post I will focus on storage in Windows Azure. Stay tuned.