I've been putting together the content for a talk that I'm doing at the ArchSummit 2012 in China next month about designing for security* (如何设计安全的架构) and one of the things I'll be talking about is when to use an n-tier architecture (where typically n=3) from a security point of view. But this got me thinking about n-tier architectures in general given that it's now 2012. I often see n-tier architectures presented in my training course when groups are designing a solution for the case study, but sometimes the justification is weak.
Traditional wisdom says that 3-tier architectures are "good". Is this still true in 2012? Let's keep this simple and restrict our thinking to the domain of Internet facing web applications that use a 3-tier architecture consisting of physically separate web server (web-tier), application server (middle-tier) and database (data-tier).
After some digging around, I found this blog entry by Mike Hadlow called You Don't Need an Application Server, where he's referring to middle-tier application servers rather than products that are badged as application servers (e.g. WebSphere, JBoss, etc). It's worth a read because it challenges a number of common preconceptions.
Rather than simply agree with the title of his blog entry, I want to ask, "when do you actually *need* a 3-tier architecture?". The answer to this question isn't black and white at all because much of the time the use of a 3-tier architecture depends on the context of where you are and what you're trying to achieve. Here are some common arguments and counter-arguments concerning the use of a middle-tier application server.
The list above is only a quick summary of some key points but one counter-argument for all of the concerns above is the increase in cost and complexity. Creating a 3-tier architecture is relatively straightforward, but getting it right involves a good deal of effort. I still remember the panacea created by J2EE application server vendors that basically said, "don't worry about security, scalability, transactions, etc ... we'll do all that for you!".
When making architectural decisions, context is key. Often the reason for introducing a physically separate application server is because "our organisation doesn't permit SQL traffic from machines in the DMZ". It's certainly *a* reason, but perhaps one that should be challenged, particularly if reducing cost and complexity are important. You *will* be making some trade-offs and it's crucial that understand what they are.
Back to my original question then ... when do *you* use a 3-tier architecture and why?
* Of course, the irony of this talk is that I'm not a security expert and that's really the point. As a technical lead/software architect, you can't be a specialist in everything but you do need a general awareness so that you can try to do "the right thing", knowing where to get help from those that are specialists.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.