When do you need a 3-tier architecture?

Context is key, understand the trade-offs

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).

You don't need an application server

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.

Except when you do

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.

  • Security: A physically separate middle-tier application server can increase security because it adds an extra level of indirection between the web server and the database. This means no direct route from the web server to the database server and (e.g.) SQL protocols/ports don't need to be allowed/opened on DMZ firewalls. If your web server gets hacked, your application server is safe. Also, the attack surface on the web server is reduced because there is a reduced amount of code, etc running on the web server. As a counter-argument, adding a level of physical indirection doesn't necessarily provide more security. In reality, how good are we as developers at creating secure middle-tiers? Security context propagation is complex and I've seen many middle-tiers that simply wrap up business logic/data access and expose them to the web-tier as a collection of unsecured web services.
  • Performance and scalability: A 3-tier architecture is more scalable than a 2-tier architecture because the web-tier and middle-tier can be scaled differently if necessary. An application server can be used to cache persistent data to increase performance and scalability. Counter-arguments include that scaling just a web server is simpler and caching could be done either locally in the web server or by duplicating the data in a different format (e.g. a NoSQL store alongside a SQL database).
  • Reuse and maintenance: A single physical middle-tier can be shared by a number of clients, so reuse and maintenance is increased. As highlighted in Mike's blog entry, a counter-argument is that this is possible by creating reusable components that are simply deployed multiple times.
  • etc...

Context is key, understand the trade-offs

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.

About the author

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.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: When do you need a 3-tier architecture?

Multiple tiers add (a little) security by creating a network "perimeter", if they are correctly firewalled. At the same time, "hacking" these days is often about applications and stealing data, which makes network security and the concept of perimeter much less relevant than in the past. If your web server talks to the database through any number of tiers and your web application is vulnerable to SQL injection, then the database will be dumped through the web app.

Re: When do you need a 3-tier architecture?

Two circumstances when I always set up a separate app tier are when using Smart Clients and for SharePoint web parts (my personal preference is to minimize what's deployed to the SP web front end boxes). For "normal" ASP.Net sites I go with 2 tiers (of course, if I make use of a service external to my app, that increments the tier count). By using a chunky, message based design for my business layer I can switch if needed from 2 to 3 tier merely by adding some config entries and swapping the proxy that the presentation layer uses (one for "direct " access, another for via a service layer).

Re: When do you need a 3-tier architecture?

I don't think n-tier, or rather, tiers, are the way to go. For some features, it makes sense to have multiple layers of services. For other features, it doesn't. Why constrain your entire application to fit into n tiers when for some things it's overkill and for others it's not enough?

I personally prefer lots of small components, offering APIs or consuming messages, that do one thing and one thing only. These get plumbed together to make a single service. With the right deployment environment, new services are simple to add. Horizontal scaling becomes much easier, with performance problems being localised to single services, and much easier to address, since drastic changes like rewrites and complete datastore changes are feasible. Code bases remain small and simple, and can be written in the right language using the right technologies for the job - a comet API might use NodeJS while the authentication service uses Scala. If it turns out that you chose the wrong database for a service, it's easy to replace, we replaced the database of a feed service in a large social network with zero downtime in only a few months, including all the work that was done in performance testing and proving that the new database was the right tool for the job.

Re: When do you need a 3-tier architecture?

I'm not sure +1 tiers == greater performance. For starters you have to negate the transactional costs of communication between the two which includes network I/O. Testing and debugging can also be a lot harder. When your system blows, you need good error logging to know exactly where it went wrong. And to do that you have to pass errors between tiers.

Re: When do you need a 3-tier architecture?

For me, 3-tiers architecture is mainly used to support two non-functional requirements: reusability of business logic and distinct governance (or SLA). Security for 2-tiers architecture can be as efficient as the one for n-tiers architecture. (as an example, most WCM in banking companies are 2-tier and have strong security) I believe Security and Infrastructure must adapt themselves to application architecture, not the opposite. Scalability is not a question of number of tier in your architecture. But, in a web architecture, typical web servers cannot scale vertically easily (e.g. number of connections limited by number of available system threads). This scalability issue can generally be solved if you use a 3-tiers architecture: use messaging paradigm (execution queues) between your web server and your application server to increase scalability: horizontal for web servers and both for application servers.

Re: When do you need a 3-tier architecture?

I have a question about Three-tier architecture from a secure architecture viewpoint that I was hoping you could provide guidance on. Currently, I see implementation where web servers sit in the DMZ and there's a firewall rule that allows ports 80/443 to pass through to back-end servers/services - application servers, database servers, authentication servers (LDAP/AD/etc). To me this is the wrong way (and an very insecure way) to implement web services, as I believe the calls to these back-end servers/services should not flow over ports 80/443, but should be application calls. I believe there should be another server in the DMZ that the web server DMZ makes a call to first. Then on that second DMZ server, the request for back-end servers/services is requested and converted to a true application/web service call, which then in turns make a request through the firewall using an application/service port, and not 80/443. Wanted to get your thoughts on this. Thx, Jeff

Re: When do you need a 3-tier architecture?

I agree with the points being made here and I think I am going to advise against plans in my department to move an existing web app from 2 to 3 tiers by moving the class library projects from the web server to a new application server. However, can I ask the question - is it possible to deploy the components to the new server and have the website reference them there purely by configuration, or would we need to develop a web services to expsose all (100's) the methods and then have the website reference the web services?

Re: When do you need a 3-tier architecture?

If you're going to deploy your components on another server, you'll need some kind of inter-process communication in order to use them. So yes, if I've understood correctly, you'll need to implement a web services/REST/RMI wrapper on the new server and then build clients on the web server, taking things like performance and security into account as needed. This is likely not going to be a small undertaking.

Add a comment Send a TrackBack