N-tier on the Cloud

In my previous post, I briefly highlighted that layering is still relevant in Cloud Applications and Architects should be focusing on the distribution (tiering) aspects of application components in the Cloud instead. In this post, we are going to examine a common strategy that most of us today would imagine when deploying layers to the cloud.

Consider the following deployment pattern which is common in on-promise Enterprise applications where the Presentation layer is deployed to a web farm and the rest of the layers are deployed to an Application farm with a database cluster serving the application. In larger enterprise applications, where common operation data stores are available, the data layer maybe separated into its own farm creating a typical n-tier environment.

There is a temptation to apply the same philosophy when we are thinking of deploying to the Cloud. The Windows Azure Platform provides roles where we can deploy our layers and it is common to envision our deployment topology to be somewhat like the following:

While this makes sense, there are several points that deserve our consideration:

1. Worker roles in Azure behave like Windows Services and they employ an async pattern.
2. Web roles and Worker roles communication are best done via Queues
3. There is now an associated cost to the number of instances in our architecture.

Traditionally, application architecture was purely focused on maintainability, extensibility and up to some extend, the elegance of the application. There is no cost of usage associated to the server(s) that have already been provisioned in the datacentre. However, when deploying to the Cloud, there is now an additional Cost dimension to consider. Since, one of the benefits of the cloud is Pay-per-use, we need to ensure that our application is not consuming more resources than required.

Take note that services offered on Azure (at the time of this writing) is equivalent to renting a car. We can rent a car for a day and not drive it but we will still get billed. The similar concept applies to our provisioned services on Azure today.

Another cost factor that is often missed out during consideration is the cost for environments. Azure provides a staging and deployment environment and that effectively double the cost of our instances. Therefore the cost for our compute services for a single instance per role per month for the architecture above is:

(2 instances x 24 Hours x 30 Days) x (Staging + Production environment) = 2880 Compute Hours

and this calculation has not taken storage services charges into consideration yet.

By now, we should get the picture of how cost plays an important part in influencing Cloud application architectures. It is not to say that the above deployment strategy is discouraged. If the application is large enough to warrant such separation of code for fine tuning and distribution of load, the above strategy works fine.

In the next post, I will discuss how layering would look like in the Cloud.