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. While we can attach our debugger to our local instance of the Development Fabric, we cannot debug applications remotely that have been deployed in Windows

Azure. We will need to maintain our logging and use it to debug issues, if present in the cloud. Because we are not guaranteed to browse our web application on the same server after every call, there is no persistence with local storage. Microsoft answers this issue quickly with table and blob storage. All data and files that need to be accessible need to be saved in a storage service or a SQL Azure database (the highly scalable option is using storage services).