Software Architectural Patterns: N-Tier Layered and Microservices

My dear reader, how are you? السلام عليكم

In this post, we will be discussing software architectural patterns. Following previous posts from web-journey will help you move forward from here:

  1. How a Web Application Works: From Beginning to Boundaries (DirectMe)
  2. Web Services: A dive into yesterday and shaping today (DirectMe)
  3. Software Architecture: An Abstract Introduction (DirectMe)

Layered or N-tier Pattern

We will start with the most common architectural pattern, i.e., layered or N-tier pattern. A most common 3-layers architectural pattern is shown in Figure 1; including a presentation layer (most commonly containing business rules) dealing directly with the user/client, business layers containing the business logic and the data-access backend layer interacting with the database. Each layer interacts with each other using API’s. Image result for layered architectural style

Fig. 1: A 3-layered architectural pattern

What is a layer is this pattern? You can think of a layer as an application; a small independent portion of the system. It can be a single program file, modules, libraries, and packages; and, it can be something more sophisticated but the key idea is that each layer should be independent. From independence, came in my mind a quote here, “Freedom cannot be bestowed — it must be achieved.” So, achieving independence of layers in an N-layered architectural pattern is trivial. Well, layered systems are nowadays becoming less popular and the rules of the layered patterns are not respected. Developed usually start writing code without keeping an architectural pattern in mind and then end up in separating the piece of codes into layers. This ultimately returns a big-ball-of-mud. And as the system grows, achieving the independence of layers becomes difficult and it greatly affects the scalability and agility of the software. Each layer responds to the layers above in a system called closed layered pattern. But since the layers are independent, the request can be made to layers bypassing one or more layers in a system called open layered system. This reduces latency. Variations of layered patterns include flexibility of the number of tiers (2-tier, 3-tier, 4-tier, or N-tier), closed/open layers and cacheable layers. Revise the concepts 1) DirectMe, and 2) DirectMe.

Planning to develop an application using a layered pattern? Steps are below:

  1. Group functionalities specific to one aspect of the system. In this, you are free to decide the name and number of layers and choose how big a layer would be.
  2. Develop the layers and decide which one will be open. It is advisable to keep the layers close unless there is no other choice. Also, APIs should be written up properly in this step for each layer’s communication.
  3. Setup a messaging method in between the layers. It can be an HTTP protocol but in any case, it should be well defined. And,
  4. decide the communication model and design the request flow model, i.e., a top-down or bottom-up approach.

Microservices Architectural Pattern

Another architectural pattern has risen and been widely adopted by the developers’ community as an alternative to layered or service-oriented architectures called the micro-services architectural pattern. Let us explore it in detail now. Figure 2 explains the basic architecture of microservices pattern. Related image

Fig. 2: A Microservices architectural pattern

 Let us first explain the service. A service could be anything from a single function to a group of classes that combine and cooperate for it to achieve a sort of functionality. The service should be micro or it should have a single or small functionality, e.g., say, producing a pdf. Each service should be an independently deployable unit and they should be separate from each other. The overall system must be loosely coupled. The most common approach to implement a microservice architectural pattern is as below.

Implementing a  microservice pattern is just simply to split up the layers into chunks of functionalities or services. We keep on breaking the layers into sub-components until we reach a point where the application can be described as a collection of all independent and micro level services. Explore it in more detail from following resources, 1) webDev Cave tutorial DirectMe and 2) edureka tutorial DirectMe.

In the next post, I will be discussing one more architectural pattern, i.e., microkernel architectural pattern in detail and will share a few resources to learn more about it in detail.

Software Architecture: An Abstract Introduction

My dear reader, how are you? السلام عليكم

Without requirements and design, programming is the art of adding bugs to an empty text file – Louis Srygley

In this post, we will add another few concepts to our ‘web-journey‘ and understand the software architectures of modern-day and optimized web applications. Before jumping in directly, I suggest revising a few basics from previous posts: 1) DirectMe, and 2) DirectMe.

Building software is not just coding! and it is nothing new in this statement but most software developers forget to keep it in mind when it comes to building software. It eventually leads to creating a loophole in the software system. Creating software involve a lot of activities and phases and they are all important. I will now list all of them from start to end and give a few links to tutorials that explain each process in finer details. It starts with requirements engineering (what does that mean? DirectMe. what is it in case of software? DirectMe), analysis (what is software analysis? DirectMe), design (DirectMe), development, testing (what is software testing life cycle? DirectMe. You should also be knowing user acceptance testing DirectMe), acceptance (DirectMe), and deployment (DirectMe). Well, there is another crucial and important phase after deployment, i.e., maintenance and regular update (DirectMe). Let us revise them all in a summarized tutorial DirectMe.

Each stage requires an input from the previous stage and should result in a defined output. So with all this information, it is now easy for us to define software architecture. Software architecture is:

  1. how the defining components of a software system are organized and assembled,
  2. how they communicate with each other, and
  3. the constraints the whole system are ruled by.

The first part is also called an architectural pattern. The second part mainly refers to APIs through which the components talk to each other.  The third part refers to the non-functional attributes and is mainly concerned with quality attributes, i.e., scalability, resolvability, resilience, and adaptability etc. Some developers also call it the ilities of the software. It is important to keep it in mind as it impacts the software development phase. Many developers make a mistake and use the term software architecture and architectural pattern interchangeably. This confusion arises with their understanding of designing the architectural pattern as a major component of the software. Which actually is not true as you have already learned in the above definition of software architecture. In short, the architectural pattern is a part of software architecture and it refers to the overall structure of the software on which your code will be structured. Some common examples of architectural patterns include layered architectural pattern, microservices pattern etc. The architectural pattern defines the granularity of the pattern which also means how big or small should the individual component be.

What is the difference between the architectural pattern and the design pattern? Architectural pattern deals with the high level and universal components of the software and helps to understand how the individual components are organized and assembled. However, the design pattern goes to much deeper details and has a lower-level scope. It explains how the individual components should be built. So they both have a different scope but they do relate with each other. There comes a time when the architectural pattern restricts to have a specific design pattern in software. Architectural patterns are of many types, e.g., monolithic, service-based, or distributed. These patterns can be layered (n-tier), microservices (service-based) and event-driven (or plugin pattern) schemes. There are two more common patterns, i.e., service-oriented architectural patterns and space-based architectural pattern. Want more details? I would recommend a book which explains all of this in a very abstract way DirectMe. Design patterns can be creational, structural and behavioral.

In the future post, we will discuss each architectural pattern in detail. Stay in touch!