What does N-tier Architecture mean nowadays?

In a traditional sense, N-tier means separating the application into "tiers" and putting each "tier" on different servers. This was done for at least 3 reasons:

1. Maintenance:

   a) Code Maintenance: Easier to do bug fixes and feature additions.

   b) Hardware Maintenance: Taking one server down does not disrupt service from other tier.

2. Performance: One server was often not fast enough to ha开发者_开发知识库ndle web requests, business logic computations, and database/file access at the same time.

3. Scalability: Specifically horizontal scalability

   a) Fault Tolerance: Ability to have more than 1 physical server per tier means when 1 server is down, the application can still function as a whole.

   b) Load-balancing: Having multiple instances of a tier helps service large amount of requests.

Nowadays, hardware and networks are fast enough to serve thousands of requests per second on a single server. Also, the buzz word for IT right now is "consolidation". So even if the application is split into tiers, they probably will end up hosting on virtual machines on a single server.

I think nowadays when people talk about N-tier architecture, they are talking about separation of concerns within the application. It is more of a logic separation than a physical one. I think as long as we achieve good separation of concerns and loose coupling, applications do not have to be N-tier. It just seems that many programmers think that N-tier architecture is a golden standard that every web application must comply with.

So, what is N-tier architecture to you nowadays?

From wikipedia article I read:

Generally, the term tiers is used to describe physical distribution of components of a system on separate servers, computers, or networks (processing nodes). A three-tier architecture then will have three processing nodes. Layers refer to a logical grouping of components which may or may not be physically located on one processing node.

I do think that the concept of "layer" and the concept of "tier" got mixed up with time. I personally like to talk about layers only rather than tiers as I prefer PAAS solutions where my concerns are only on the software, and the industry is slowly moving in this direction.

Also when you plan for an application that could greatly expand I still don't think that you should think about n-tier for scalability. In fact, very popular websites with a lot of traffic only separate themselves into 3 components: Database servers, web servers (including the caching servers), and a few CDN (content delivery networks). This kind of separation can be achieved in any application.

But to conclude, I think a programmer should only think abuot layers and separation of concerns within the application to achieve the most important (and difficult) task: maintainability in the long run.

Security for one? I'd rather you hit my web servers than my app servers!

I think it is, and always has been, an artificial distinction. I agree with your premise that it refers mostly to logical separation of components these days. However, there are still plenty of applications that are too big (use wise or data-wise) to fit on a single machine, so the idea of separating an application into discrete components for scalability reasons is definitely not dead.