As submitted to http://acanac.org/blogs/geek/

In my line of work, I would be classified as a hybrid to what Microsoft calls a Systems Architect and an Application Admin.  One of my jobs is to provide insight and input on solution architectures that our organization is planning to build.  As easy as this may seem to many of you, the process can be quite draining.  We have application architects on staff who are brilliant at what they do.  They design applications using patterns and practices that have been laid out by Microsoft.  They use the latest and greatest technologies and techniques to ensure that our applications are top notch and ahead of the curve.  There's only one problem.  They sometimes forget that all of our applications are hosted on a shared, n-tiered infrastructure.

When I first started in this area I was relatively naive.  It made sense to me that the shared piece was irrelevant.  Obviously if the applications are well architected, then they will function just fine in our infrastructure, right?  Wrong.  Even though our shared infrastructure is well designed and maintained, not every solution is going to be a good fit for it.  For starters, the infrastructure is of a 4-tier nature.  We have a web farm presentation tier, a server cluster application tier, and a completely separated database cluster data tier.  If the application uses a 3-tier design then the application service layer, where the business logic is processed, is executed in the presentation tier.  I can tell you first hand, that's not good.

You see, web servers and web farms are built to be scaled horizontally.  Whenever the load is too great on the presentation tier, we add more web servers to the farm.  We don't add more ram, or processing power, we simply add more servers to handle more connections.  However, when the application tier reaches capacity, we increase the ram and cpu power.  If necessary, we add another server to the cluster, creating the appearance of more ram and cpu power.  Due to the nature of the scalability of each farm,  we have created an optimal cost situation by isolating components of the application to servers that are designed to scale just for that component.

Don't get me wrong, I am not saying the 4-tier is the be all end all.  It's not for everyone.  It works for us, because we have an enterprise class deployment.  I am also a big fan of the 3-tier deployment, my only point is that you can't mix the two.  What happens is that an application eventually starts using more resources than the web server can provide.  We add another server and it doesn't help.  Why?  Easy, it's because web front ends are not supposed to do much, so we scale them horizontally.  Scaling them vertically wouldn't be cost effective. 

If you work in a .Net development shop as an architect, please try to remember that there are other areas of architecture that need to be consulted for each and every new solution.  Application Architecture, System Architecture, Security Architecture and Application Hosting (Administration).  You will be a lot better off and your solutions will implement with ease.

For some more information on the subject, check out the following Microsoft Patterns and Practices sites:

• Tiered Distribution
• Deployment Plan
• Deployment Patterns
• Enterprise Solutions Patterns Using .Net