I've seen quite a few developer job postings recently that include a sentence that reads more or less like this: "Must have experience with N-Tier architecture", or "Must be able to develop N-Tier apps".
This leads me to ask, what is N-Tier architecture? How does one gain experience with it?
In software engineering, multi-tier architecture (often referred to as n-tier architecture) is a client-server architecture in which, the presentation, the application processing and the data management are logically separate processes. For example, an application that uses middleware to service data requests between a user and a database employs multi-tier architecture. The most widespread use of "multi-tier architecture" refers to three-tier architecture.
It's debatable what counts as "tiers," but in my opinion it needs to at least cross the process boundary. Or else it's called layers. But, it does not need to be in physically different machines. Although I don't recommend it, you can host logical tier and database on the same box.
Edit: One implication is that presentation tier and the logic tier (sometimes called Business Logic Layer) needs to cross machine boundaries "across the wire" sometimes over unreliable, slow, and/or insecure network. This is very different from simple Desktop application where the data lives on the same machine as files or Web Application where you can hit the database directly.
For n-tier programming, you need to package up the data in some sort of transportable form called "dataset" and fly them over the wire. .NET's DataSet class or Web Services protocol like SOAP are few of such attempts to fly objects over the wire.
It's based on how you separate the presentation layer from the core business logic and data access (Wikipedia)
N-tier data applications are data applications that are separated into multiple tiers. Also called "distributed applications" and "multitier applications," n-tier applications separate processing into discrete tiers that are distributed between the client and the server. When you develop applications that access data, you should have a clear separation between the various tiers that make up the application.
A typical n-tier application includes a presentation tier, a middle tier, and a data tier. The easiest way to separate the various tiers in an n-tier application is to create discrete projects for each tier that you want to include in your application. For example, the presentation tier might be a Windows Forms application, whereas the data access logic might be a class library located in the middle tier. Additionally, the presentation layer might communicate with the data access logic in the middle tier through a service such as a service. Separating application components into separate tiers increases the maintainability and scalability of the application. It does this by enabling easier adoption of new technologies that can be applied to a single tier without the requirement to redesign the whole solution. In addition, n-tier applications typically store sensitive information in the middle-tier, which maintains isolation from the presentation tier.
Taken from Microsoft website.
If I understand the question, then it seems to me that the questioner is really asking "OK, so 3-tier is well understood, but it seems that there's a mix of hype, confusion, and uncertainty around what 4-tier, or to generalize, N-tier architectures mean. So...what's a definition of N-tier that is widely understood and agreed upon?"
It's actually a fairly deep question, and to explain why, I need to go a little deeper. Bear with me.
The classic 3-tier architecture: database, "business logic" and presentation, is a good way to clarify how to honor the principle of separation of concerns. Which is to say, if I want to change how "the business" wants to service customers, I should not have to look through the entire system to figure out how to do this, and in particular, decisions business issues shouldn't be scattered willy-nilly through the code.
Now, this model served well for decades, and it is the classic 'client-server' model. Fast forward to cloud offerings, where web browsers are the user interface for a broad and physically distributed set of users, and one typically ends up having to add content distribution services, which aren't a part of the classic 3-tier architecture (and which need to be managed in their own right).
The concept generalizes when it comes to services, micro-services, how data and computation are distributed and so on. Whether or not something is a 'tier' largely comes down to whether or not the tier provides an interface and deployment model to services that are behind (or beneath) the tier. So a content distribution network would be a tier, but an authentication service would not be.
Now, go and read other descriptions of examples of N-tier architectures with this concept in mind, and you will begin to understand the issue. Other perspectives include vendor-based approaches (e.g. NGINX), content-aware load balancers, data isolation and security services (e.g. IBM Datapower), all of which may or may not add value to a given architecture, deployment, and use cases.
N-tier data applications are data applications that are separated into multiple tiers. Also called "distributed applications" and "multitier applications," n-tier applications separate processing into discrete tiers that are distributed between the client and the server. When you develop applications that access data, you should have a clear separation between the various tiers that make up the application.
And so on in http://msdn.microsoft.com/en-us/library/bb384398.aspx
When constructing the usual MCV (a 3-tier architecture) one can decide to implement the MCV with double-deck interfaces, such that one can in fact replace a particular tier without having to modify even one line of code.
We often see the benefits of this, for instance in scenarios where you want to be able to use more than one database (in which case you have a double-interface between the control and data-layers).
When you put it on the View-layer (presentation), then you can (hold on!!) replace the USER interface with another machine, thereby automate REAL input (!!!) - and you can thereby run tedious usability tests thousands of times without any user having to tap and re-tap and re-re-tap the same things over and over again.
Some describe such 3-tier architecture with 1 or 2 double-interfaces as 4-tier or 5-tier architecture, implicitly implying the double-interfaces.
Other cases include (but are not limited to) the fact that you - in case of semi-or-fully replicated database-systems would practically be able to consider one of the databases as the "master", and thereby you would have a tier comprising of the master and another comprising of the slave database.
Mobile example
Therefore, multi-tier - or N-tier - indeed has a few interpretations, whereas I would surely stick to the 3-tier + extra tiers comprising of thin interface-disks wedged in between to enable said tier-swaps, and in terms of testing (particularly used on mobile devices), you can now run user tests on the real software, by simulating a users tapping in ways which the control logic cannot distinguish from a real user tapping. This is almost paramount in simulating real user tests, in that you can record all inputs from the users OTA, and then re-use the same input when doing regression tests.
When we talk of Tiers, we generally talk of Physical Processes (having different memory space).
Thus, in case, Layers of an application are deployed in different processes, those different processes will be different tiers.
E.g, In a 3-tier application, business tier talks to Mainframes (separate process) and talks to Reporting Service (separate process), then that application would be 5 tier.
Hence, the generic name is n-tier.
from https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier
An N-tier architecture divides an application tires into logical tiresand physical tiers mainly and their are divide to sub parts.
Layers are a way to separate responsibilities and manage dependencies. Each layer has a specific responsibility. A higher layer can use services in a lower layer, but not the other way around.
Tiers are physically separated, running on separate machines. A tier can call to another tier directly, or use asynchronous messaging (message queue). Although each layer might be hosted in its own tier, that's not required. Several layers might be hosted on the same tier. Physically separating the tiers improves scalability and resiliency, but also adds latency from the additional network communication.
A traditional three-tier application has a presentation tier, a middle tier, and a database tier. The middle tier is optional. More complex applications can have more than three tiers. The diagram above shows an application with two middle tiers, encapsulating different areas of functionality.
An N-tier application can have a closed layer architecture or an open layer architecture:
In a closed layer architecture, a layer can only call the next layer immediately down.
In an open layer architecture, a layer can call any of the layers below it.
A closed layer architecture limits the dependencies between layers. However, it might create unnecessary network traffic, if one layer simply passes requests along to the next layer.
An N-tier application is an application which has more than three components involved. What are those components?
All the social applications like Instagram, Facebook, large scale industry services like Uber, Airbnb, online massive multiplayer games like Pokemon Go, applications with fancy features are n-tier applications.
Martin Fowler demonstrating clearly:
Layering is one of the most common techniques that software designers use to break apart a complicated software system. You see it in machine architectures, where layers descend from a programming language with operating system calls into device drivers and CPU instruction sets, and into logic gates inside chips. Networking has FTP layered on top of TCP, which is on top of IP, which is on top of ethernet.
When thinking of a system in terms of layers, you imagine the principal subsystems in the software arranged in some form of layer cake, where each layer rests on a lower layer. In this scheme the higher layer uses various services defined by the lower layer, but the lower layer is unaware of the higher layer. Furthermore, each layer usually hides its lower layers from the layers above, so layer 4 uses the services of layer 3, which uses the services of layer 2, but layer 4 is unaware of layer 2. (Not all layering architectures are opaque like this, but most are—or rather most are mostly opaque.)
Breaking down a system into layers has a number of important benefits.
• You can understand a single layer as a coherent whole without knowing much about the other layers. You can understand how to build an FTP service on top of TCP without knowing the details of how ethernet works.
• You can substitute layers with alternative implementations of the same basic services. An FTP service can run without change over ethernet, PPP, or whatever a cable company uses.
• You minimize dependencies between layers. If the cable company changes its physical transmission system, providing they make IP work, we don’t have to alter our FTP service.
• Layers make good places for standardization. TCP and IP are standards because they define how their layers should operate.
• Once you have a layer built, you can use it for many higher-level services. Thus, TCP/IP is used by FTP, telnet, SSH, and HTTP. Otherwise, all of these higher-level protocols would have to write their own lower-level protocols. From the Library of Kyle Geoffrey Passarelli
Layering is an important technique, but there are downsides.
• Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes. The classic example of this in a layered enterprise application is adding a field that needs to display on the UI, must be in the database, and thus must be added to every layer in between.
• Extra layers can harm performance. At every layer things typically need to be transformed from one representation to another. However, the encapsulation of an underlying function often gives you efficiency gains that more than compensate. A layer that controls transactions can be optimized and will then make everything faster. But the hardest part of a layered architecture is deciding what layers to have and what the responsibility of each layer should be.
