I'm presently creating architecture for my new project. It has ASP.Internet MVC web client and WCF web services for 3rd party integration as front-finish.

Presently this application is going to be located by us on leased rack space in datacenter, however in future we may move it to Microsoft Azure.

Must i do specific planning Azure during my architecture? Or my current architecture that has IIS, MSMQ, SQL Server, Velocity, etc works in Azure without an excessive amount of issues? I've been ignorent about Azure because of insufficient available time, but have to make certain which i obtain the architecure suitable for future need.

Do you know the things I have to watch out for?

Thanks &lifier Regards,

Ajay

It is dependent how seriously you are thinking about moving to Azure and just how soon. If you're, then I'd say yes.

Regrettably, the thought of having the ability to write once run anywhere is a little of the fantasy. The idea of abstracting everything away just does not work when the platform limits your architecture options - and virtually every platform does. Even when you are able to choose your computer data persistence technology for instance, you are almost certain to encounter an impedance mismatch problem sooner or later which will affect your design.

So in Azure's situation you will find numerous issues you will need to consider.

First of all, no MSMQ or Velocity at this time. Azure has it's own queueing component which has much more of a passive model (poll for messages, no routing, etc), which means you may have the ability to use that, but it is not transactional in the same manner that MSMQ is, and you will need to ensure all messages are idempotent. Distributed caching is on it's way In my opinion, but it is not there yet (and might not be Velocity).

Next, you may either choose Azure's Table Storage or SQL Azure Database for the table-like persistence. Which you select most likely is dependent on in which you scale discomfort points are. The simplest option is to visit the SQL route, but you will find certain restrictions there with DB size, and also you will not have the ability to use most of the services around SQL Server, such as the job agent, dependencies (for cache callbacks), etc. And when you are running into issues where SQL Server is not scaling, then running within the cloud is not prone to help much, just because will still be an RDBMS. If you prefer a more scalable solution, then Azure Table Storage is the guy - but it is non-relational and you will need to modify your architecture to support the greater limited scope of transactions it supports - along with the natural restrictions of their querying mechanism and latency from the Relaxation-HTTP architecture. Think BASE, not Acidity.

Third, you will need to consider file storage in a different way. As all of your instances is running inside a VM, any nearby storage vanishes once the VM shuts lower, so for long-term persistence, you will need to use Azure Blob Storage and design your application keeping that in your mind.

Furthermore, you have a selection of two kinds of roles - web roles, running IIS (that you simply presently don't have any charge of, when it comes to fine-tuning IIS parameters) and worker roles, that are a lot more like home windows services. And there is no mechanism for the roles to understand one another - so communication from web to worker happens through the queues, or table/blob storage. So you will need to take this into account too.

So that all up, plenty of design choices will have to be made if you wish to proceed to Azure - the working platform, by it is extremely character, limits what technologies you should use, and for that reason what design choices are accessible to you. Should you choose design with Azure in your mind, then you'll finish track of a far more naturally scalable system, but you will find certain choices that require to made on the way - plus some might be deal breakers.

[Edit: I ought to include that this response is more targeted in the thought on moving your whole application to Azure. This, obviously, is not the only real option - you might like to only move certain components towards the cloud and keep your relaxation on-premise, interacting using something similar to Azure .Internet Service Bus for instance]