ThinkingCog

Articles written by Parakh Singhal

N Tier vs. N Layer

Background

When software development started out, the software made was relatively simple and the industry was still climbing the learning curve. Even with procedural languages, layering of source code was done so as to allow a logical separation of responsibilities and concerns. This got to the next level with the introduction of object oriented languages and the entities forming the problem domain in the source code acquired a layer of their own. As the complexity of softwares developed increased aka the functionality offered by the softwares in general increased, so increased the number of layers. With consolidation of IT assets, came the next wave of computing in the form of client – server computing with softwares living life at a single place - server rather than living individually on client computers. As the number of consumers increased, measures were taken to tackle the workload and here is where the concept of layers was taken further to introduce the concept of tiers. The tiers were simply layers bound together in one physical unit, primarily made from the perspective of scaling (installing on more than one machine). The unit of layers could depend upon other such units to provide the required functionality and have some kind of communication ability depending upon the environment and usage scenario.

So after formal background information as to why layers and tiers exist, we can now focus on what exactly is the core difference between the two. An accepted difference exists as follows:

Difference between Layer and Tier

Layers emphasize logical grouping of related functionality while tiers signify the physical separation of such logical groups. An easy way to visualize this is by imagining that all your code resides in a single project and is running on a single server in a single process, while in case of a tiered approach the tiers are located on a single machine and being handled by different processes and communicating among themselves via some mechanism to achieve the desired outcome.

A typical software project consists of 3 layers – Presentation, Business Logic Layer (BLL) and Data Access Layer (DAL).

Layer vs Tier

 

 

 

 

 

 

 

 

 

 

 

It is when there are more than 3 layers, that your project can be termed as an N-Layer project. Similarly when your project contains more than 3 tiers, it is accepted to term it is an N-Tier project.

Different cases can exist when we talk about tiers:

1. Single machine, single process: the simplest case, tiers can exist on a single machine and can be handled by a single process.

Single Machine Single Process N Tier

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Single machine, n processes: A scenario where each tier is being handled by a dedicated process.

Single Machine N Processes N Tier

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3. True N Tier: Where each tier is hosted on a separate machine and is being handled by a dedicated process.

N Machines N Processes N Tier

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

So one might wonder why we would convert a layered project to a tiered one. Mainly three reasons come to my mind:

1. Performance: Separating out the layers into tiers can give performance benefits as it gives us an opportunity to harness the processing power of more than one computer.

Example: One server can be made responsible to process traffic related to business logic, one to handle the data access, while if the UI load cannot be handled on one server, it can be made to be served via two servers. Thus we only increase the hardware where it is needed, giving us a flexible and performance centric solution.

2. Scalability: Scalability means the ability to handle increased workload. That in IT world means the ability of software to handle increased workload via expansion into additional hardware. Translated, it means that tiers can be moved to additional hardware according to the needs and made to handle the additional growth.

Examples:

a) If users of an application experience a slowdown, it might be an issue of the Data Access Tier requiring more horsepower. Thus we can expand only that tier with the help of additional hardware.

b) If an application experiences peak load only during certain times of the day, then it is a prime candidate for being made in a tiered fashion. Say, in the morning time the application needs to be served by a set of two servers on a per tier basis, but by noon the load decreases to an extent that it can be handled by only one set of servers on a per tier basis.

3. Fault Tolerance: Critical applications are served by redundant servers i.e. more than one server serving the same version of an application. This is done so that in case when one of the servers goes down, the other server can take over and continue to serve the application. This can be extended to tiers, when more than one server serves the same version of a tier, thus providing fault tolerance. In most of the cases these servers are load balanced using some kind of a load balancing scheme.

Now that we have learnt about the benefits of tiers, let’s learn to apply this pragmatically. Whenever we work with tiers, we have to deal with inter physical boundary communication in order to make tiers work with each other. Physical boundary is defined by either a process within which the tier is running when all the tiers are available on the same machine or by a network boundary when they are available on different machines and have to communicate across network in order to work together. This inter boundary communication introduces a lot of overhead not only in terms of communication latency, but also programming complexity. Thus an application should only be tiered when it meets a certain level of requirements – load conditions, performance requirements, fault tolerance and of course budget.

So all in all, play with tiers but only after doing a through cost-benefit analysis of the application and considering the life span of the application.

blog comments powered by Disqus