The traditional way to run transaction-oriented applications is with a three tier architecture, where web servers running on a cluster of 1 or 2 processor commodity machines mitigate connections to application servers running on a small cluster of 4, 8, or 16 processor machines. This is a great architecture and made a lot of sense when software was written to scale vertically and IT organizations wanted to run small clusters of UNIX machines.
Traditional Three Tier Architecture
The web tier serves static content and load balances connections to the application server tier, which serves dynamic content and connects to backends.
As part of the trend towards commodity machines, people are starting to run 1 or 2 processor commodity machines in the application tier as well as the web tier.
Modern Three Tier Architecture
When you step back and look at this evolving architecture, it begs the question:
Why have a cluster of commodity machines mitigate connections to... another cluster of commodity machines?
Consider the following architecture, where the web and application tiers are collapsed:
Since static content is now served directly from the Linux kernel, there is no performance impact of serving the static and dynamic content from the same machines. By including a reverse proxy, which most people are running now, a DMZ can be maintained in place of the web server tier's DMZ.
This architecture where we move from a triple decker club sandwich to a pancake architecture where the web and application tiers are merged together is the exact architecture deployed at every large scale web site, ranging from Amazon to E*TRADE to Google to Yahoo.
In order to deploy this kind of grid architecture in an enterprise environment, the nodes need to be able to call each other to share sessions or data. More on this evolved load balancing in a subsequent post.