Migrating Applications to Windows Azure – The Architecture
The architecture for a rich internet application leverages the same logical model that all modern applications are based on: the n-tier service-oriented model.
This diagram depicts the n-tier service-oriented layered architecture consisting of 3 layers, Presentation, Business and Data / Interop.
Of course this is the most basic version of this model and at this altitude seems pretty simple. In order to get the details of this model we need to fly in a little closer…
If you dig deeper into this model you get this more detailed diagram which depicts a client architecture with well defined separation of concerns. Presentation is divided up into UI Components and UI Processing implying a Model-View-Controller pattern. The business tier is separated into business entities, business rules and business workflows. The Data tier depicts both a store and a component to access the store. The Interop component reveals that there will be service agents or proxies which encapsulate communication with remote systems. This is the pattern we will use for our Silverlight Client.
Finally if you apply the same model to a service you will see that the layers are nearly identical except for the ‘presentation’ tier where we defines the service interface and the service processing components. This is the pattern we will use for our WCF RESTful service and server side data access and store
The physical architecture is really no different than what was used for the previous version of the application. What has changed is I am using newer versions of the tools and technology and I am using Microsoft’s cloud platform, Windows Azure, for server side compute and storage. Below is a depiction of the physical architecture as deployed to Windows Azure.
While the architecture model did not change as a result of selecting Windows Azure as my target platform, the development and deployment activities have been affected. The important point I learned form this experience is that this migration project was not a matter of moving binaries to a new runtime but instead reusing code to create a new implementation that targets the Azure platform.
This distinction is key. In moving to Azure you are not able to just point your existing application projects to the cloud and deploy. You need to create new projects based on the Azure project template and then move existing code into those projects. If you have done a good job of layering your code based on the model depicted above, you will have an easy migration to the Azure runtime.