Three-tier architecture

I’ve been doing some thinking about application architecture and some of the problems that I’ve seen with that during implementation and development.

A three-tier architecture is often used in the context of web site development, for a couple of reasons:

• It creates a clear separation of roles for each server component
• It allows abstraction of each piece
• Each role can be improved, updated, upgraded, or wholesale reworked, without impacting the rest of the system
• Redundancy is easier to build in on a function by function basis

These are all great reasons, and most successful web properties do this in some fashion. The tiers may vary in number and type, but the goal is functional separation. Despite these worthy goals, often things go awry during implementation and ongoing development.

Take the case of a typical web-app-database structure. The user makes a request of the web front end. The web layer passes the request to the app layer for processing, which usually entails a call to the database. The user cannot interact with anything other than the web layer, and only the app layer can talk to the database.

At some point, another feature is required – and quickly. The only way to get it done right now is to make an exception (just this once) to allow the web layer to make a database query directly. The tier-structure is broken. A few months down the road, a dozen one-time exceptions later, and the whole thing is one big mess. Now you can’t really tell if the redundancy you thought you had is really there. You’re afraid to change any of the pieces. What’s worse is that you’re equally afraid to fix anything in case your “fix” breaks something else.

Another thing that I see happen quite often is to confuse a logical, functional tier-structure with one that is hard-wired into the network. This need not be the case, but it is often done this way. One can certainly develop the application with a multi-tier architecture, but that doesn’t mean this needs to be built into the network.

There are a couple of good reasons to segregate your network as well:

• You have a very large network and need to deal with bandwidth and addressing issues
• Security

For most of the small to medium sized networks that I’m talking about here, only the second of those will apply.

Unfortunately, there are also few good reasons not to segregate your network this way that aren’t taken into account:

• The security you are trying to gain proves to be illusory. In most cases, the security breach will be a result of an application vulnerability rather than a network one.
• If your web server is compromised, a malicious user is a hop-skip away from everything else. The network can’t provide any safeguards in that case. It must allow traffic from your web server to your app servers in order for your application to function. Again, you have to rely on a properly secured application to thwart the bad guy from digging deeper.
• All of your internal traffic is now going through a router or firewall that will cost much more per Mb of traffic than if you did not do this. In most cases the vast majority of traffic is internal traffic that never leaves the application. You can buy a switch with a 48Gb backplane for under $2,000 today. A firewall that can pass 1Gb of traffic will cost over $50,000. And don’t forget the standby unit.

Despite all the good reasons not to segregate the network into multiple tiers, I still see this attempted all the time. I think it comes down to application developers not wanting to sacrifice development cycles for the sake of something that’s not a tangible feature. So by segmenting the network, which is conceptually easy, they can appease the security gods. Then when something goes wrong it’s a problem with the network.

My advice: Multi-tier architecture is great when enforced on application design, but not when applied to small-medium local networks. (Yes, that was a rather large qualification, but I want to be clear we’re not talking about WANs or campus-wide, inter-departmental networks here. We’re talking about web applications.)