Layered Architecture: Deployment Strategies

In my previous post, I have briefly explained the functions of each logical components in the Layered Architecture Pattern and in this post, I'll be covering the deployment architecture (or physical architecture) of layered applications.

To understand the deployment architecture of layered applications, we will first need to understand the difference between layering and tiering. Layering is the concept of partitioning code into components that form logical layers and Tiering is the term used to describe the distribution of code units to physical boundaries. In simpler terms, layering is "how you organize your code into assemblies" (.dll, .exe) and tiering is "where you deploy those assemblies".

A layered application can generally support flexible tiering through the introduction of a service layer that employs any distributed communication technologies such as DCOM, Remoting, Sockets, Message Queues, Web Services and etc. How many tiers are required will most likely depend on the security, scalability and infrastructure requirements (or constraints) of your application. You must know that performance degrades with each tier being introduced as the application will need to perform cross-process, cross boundary calls to each tier.

Generally, basic enterprise applications opt for 3-tiers (Web, App and Database) with some sophisticated ones spanning to 4 or more tiers (N-tier). The layer diagram which I presented in my previous post depicts a standard 4-layer-3-tier architecture application and it will be used as the basis for discussion in this post.

Take note that if you find the text in the diagrams too small, please refer to my previous post. I had intentionally shrunk the diagram to illustrate how the components would fit in a deployment and would expect that you are already familiarize with the color-coded boxes.

Single-Tier Architecture

The simplest way to deploy a layered application is to deploy everything to a single server. This is called the single-tier or monolithic approach. This approach is common for desktop and some types of mobile applications. It is also common when there is a server budget constraint for testing new web applications.

If you are certain that your application will not grow (which is rarely the case), you can improve the performance by completely removing the service layer.

It is generally safe to omit the service layer for monolithic client applications but I recommend to keep it there for web applications because the tendency for web applications to grow is higher. To reduce the impact on performance for the service layer in a monolithic web application, you can use the netNamedPipeBinding for the WCF/WF services.

Two-Tier Architecture

It is usually very rare to find the single-tier approach in an enterprise environment. You may find them in development servers but most of the time, enterprise applications will employ the two-tier or client-server architecture due to the need for data centralization. (Like the single-tier architecture, you can remove the service layer for performance).

The client devices or web server will host all the presentation and processing logic while accessing data from a centralized database server or a data service. 

3-Tier Architecture

Due to scalability and security concerns, typical enterprise web applications usually employ the 3-tier deployment architecture. The web servers are usually placed in a public-facing perimeter network and the application servers are placed behind a firewall within a secured network.

A properly designed service layer will enable the back-end to be accessible by external systems and client-devices. Using technologies such as Windows Communication Foundation (WCF) and ASP.NET WEB API, the service layer can provide support for a variety of client platforms including non-.NET platforms such as iOS, Android, Java and etc.

In a highly-scalable and available environment, the web servers are load-balanced into a Web Farm and the application servers are load-balanced into an Application Farm. The database servers are clustered for high-availability.

Deploying the Layered Application

If you are following closely to the project structure as illustrated in Layered Architecture Sample for .NET, you may be wondering which projects should you be deploying. For the sample Leave application, you only need to publish/deploy the Web project to the web server and the Hosts project to the application server.

You will noticed that the application server will contain the service, business and data layer assemblies whereas, the web server will only contain the presentation assemblies. This keeps business rules safe in the application server and reusable for any type of client applications.

Conclusion

I hope you find the information in this post useful. For code samples on layered .NET applications, please drop by Layered Architecture Sample for .NET.

Other posts in the series:

• Layered Architecture: Introduction
• Layered Architecture: Deploying to Windows Azure
• Layered Architecture: Applied Technologies
• Layered Architecture: Component Interactions

[Update: I have dropped the word 'Design' from the name after receiving comments from readers in facebook and MSDN Blog Malaysia, who informed me that Layered Architecture should be classified under Architectural patterns instead. I apologize for the error.]