So at almost all the Windows Azure events I’ve run around the world recently we’ve always gotten into a discussion about hooking Windows Azure applications up to on-premise systems. Indeed in a recent demo I wrote for a CRM + Windows Azure session I showed how to wire up Windows Azure applications to your on-premise CRM server. Often you’ll be using the cloud for what I call forward processing.

You should use caution here. Your Windows Azure application has the ability to scale almost infinitely. Your on-premise application does not. If you wire your Windows Azure web role directly to your on-premise system, say by making a direct Web Service call, and then your site gets slash dotted you’ve basically built your self a massive cloud hosted Distributed Denial of Service engine!

What you need to ensure that you do is buffer all of your requests from the cloud to your on-premise system via a queue of some sort. You may choose to use a Windows Azure Storage Queue for this or you may choose to use the new Queue and Router capabilities in the .NET Service bus. This means that if your Azure Web Role suddenly gets a huge amount of traffic the requests to your back end system will be queued and processed only as fast as the on premise application is able to handle them- the last thing you want is for a simple client self service application in the cloud to bring down a core business application on premise.

Obviously doing this is going to require that the call to the backend system is capable of being made asynchronously. If it’s a one way operation then it’s easy, if it’s a two way operation then getting data back to your user is generally going to be a case of having your worker role right back to to an Azure Table or indeed having a notification queue for each user that your worker role can enqueue the result onto.

In summary: If you wire your Windows Azure application directly to your on-premise application you are dicing with danger.