Considerations for the ASP.NET developer

It's easy to think developing a web role is just the same as developing a traditional website, but that's not the case. The web role is not just a website, but a complete ASP.NET web application. If we have multiple instances of our web role application running, the Azure load balancer doesn't guarantee a user's connections will all be made on the same VM. One consequence of this is that our application should either be stateless, or use the database (or table/blob) or cookies to maintain session state. In-process session state isn't an option.

Imagine a local web farm with a load balancer that does not maintain session state. The ideal solution in this case would be to use some type of session storage to maintain state across servers. This is also the case with Windows Azure web role instances. We cannot maintain state in-process if we bounce between machines; however, the state can be shared using our table/blob storage or our SQL Azure service...