Once requirements have risen above the trivial, applications have always benefited from the use of good architectures. These architectures have evolved, over time, to take best advantage of the technologies which were available. Well architected applications have the advantage of being easier to maintain and understand than un-architected ones. In addition well architected applications are easier to adapt to changes in the technology or business landscape.
Architectures almost always involve logical and/or physical separation of systems into reasonably abstracted layers. Consider the now well known “n-Tier” architecture which followed naturally from client/server. In the n-Tier architecture an application is modeled as a series of logical layers. Components of the application are placed in one of the layers. In that way we do not require that presentation layer code know anything at all about a specific data storage technology we are using. In theory this would allow us to change implementation detail at any level without great (or any) impact on the other layers. For example I could write my business logic independently of whether my data was stored in a SQL Server or Oracle relational database or in some other format. I could also change my business logic without impacting my user interface and so on.
Figure 1 n-Tier Architecture
Of course all of this depends on building a good quality logical model of the application domain and intelligently separating the model into layers. In most cases it is much more involved than simply using a wizard to bind a user interface widget directly to a SQL Server data source!
How Windows Azure has changed the playing field
While many of the concepts of n-Tier architecture continue to be relevant in Azure the fact is that there are some changes in thinking required in order to fully reap the benefits of this cloud platform. In some cases it might be possible to simply host a well architected n-Tier application in Azure. That application, however, might not necessarily be able to scale in the way that you would like. In fact, with the Azure platform, Microsoft has imposed certain restrictions and benefits on developers. Azure, itself, provides us with a basic starting architecture. As with many Microsoft technologies the probability of success is increased by understanding what those architectural realities are.
Next week’s post will discuss the simple asynchronous web/worker role architectural pattern in Azure. This pattern has some similarities and differences to the n-Tier archicture. It is one of the fundamental starting point architectures that Azure provides.
In the meantime, for an interesting (and ongoing) discussion of n-Tier apps in “the cloud” you might like Cloud Computing Google Groups.