Sticky Sessions and Windows Azure

One of the problems that often crops up with moving legacy applications to the cloud is reliance of sticky sessions. The Azure load balancer works on a round-robin basis, so if your application has been designed to work on a sticky session basis, you may have some work to do.

Although it is possible to use Sticky Sessions in Azure (see this example) it’s not a great fit for cloud architecture, for these reasons:

  1. When you provision new instances, only new sessions will be routed to them. Depending on your load balancing logic, new sessions may also still be provisioned on the old instances. This results in it taking a long time (depending on the average length of your session) for load to be evenly distributed across your instances.
  2. Cloud solutions should be designed to fail. One of your instances may be removed at any time for patching, or hardware failure. With a sticky session scenario, the clients with a session on this instance will probably have to log in again, or may see an error page, depending on your load balancing logic.
  3. Unless your load balancer shares state in some way, it’s likely that you’re load balancing with a single instance (single point of failure) and not eligible for the Microsoft SLA.
So what options are there?
  1. Use the Azure AppFabric Cache to share ASP.NET session state across your instances. This walk through shows you how, by simply changing your Web.config.
  2. Ideally move to a stateless architecture, making use of cookies or the database where appropriate. Designing an application in this way will provide you with the best scaling potential, and allow you to get the most from the cloud.
About these ads