SKP’s Thoughts: The Pains of Monolithic Architecture-Part 01
About this Article Series
Through this article series, I will discuss and present the shortcomings of monolithic architecture. Our first objective will be to understand monolithic architecture in-depth, and then we’ll explore its disadvantages, pitfalls, and shortcomings. Later, this article series will diverge into another series of articles on Microservices Architecture. SKP’s Thoughts presents my views on Software Architecture, Software Design, Software Processes, Innovative Product Design, and Software Development.
Explanation of a Typical Monolithic Architecture
The most common Software Architecture that, one can safely say, has been in existence ever since software development started is the Monolithic Architecture. There have been many forms of monolith over the ages. A single block of Software (such as Desktop), Distributed Architectures such as 2-Tier, 3-Tier, N-Tier are all examples of Monolithic Architecture. For the sake of this book, we will use the most common and standardized example of a 3-Tier Monolithic Architecture. Prior to the Microservices world, most enterprise systems would have chosen a 3-Tier for their implementation.
Tier vs Layer
Before we delve into the details of monolithic architecture, I think this will be an interesting topic to discuss. We look at the difference between a Tier and Layer from the perspective of a 3-Tier or N-Tier Web Application. Tiers are physical separations of groups, of similar or dissimilar kinds of layers, that run on the same physical infrastructure. Layers are logical or functional groupings while tiers are physically separated units. For example, the User Interface renders on browser — hence, it qualifies as a disparate existence (physical) with a specific concern (logical) — the Client Tier. Next, the Web Layer or Presentation Layer might exist along with a Business Layer, with each of them on a Web Server (Web or Presentation Tier) and Application Server (Business Tier) respectively. They may also be deployed together on an Application Server (Presentation Layer runs in the Web Container and Business Layer runs in the Application Container). Hence, this qualifies as a single grouping of deployments (physical) having different concerns (logical) — the Middle Tier. Next, the Database Schema (logical) will be on a Database Tier or Enterprise Information Systems-EIS Tier (physical). Hence, you must note that a tier is different from a layer. Note that in some web development textbooks or in practical usage — the web or presentation tier might be shown as the first one, ignoring the client tier. The user interface is rendered on the client tier by this presentation tier. The presentation tier prepares the user interface for rendering based on the data that is returned by the business tier, which gets it from the database tier. From this introduction, you can understand that tiers are physical deployments of logical layers. Groups of layers, similar or dissimilar, that operate on the same infrastructure are also said to divide into tiers.
Client Tier
Let us now get into a detailed explanation of each important tier in the 3-Tier architecture. First is the Client Tier. Now, the client tier is, physically, entirely on the client-side. In other words, it is the user interface of the application. Typically, this is rendered by the web container as in the below diagram. The end-user will interact with the application through this user interface rendered on the client tier. Our explanation is based on a web (DHTML) user interface rendered on the browser on a personal computer.
In the below diagram, the client container can be considered as a desktop user interface or a technology that renders within the specifics of that container (for the web applications, the browser can be thought of as a container). Mostly, the simple validations, filling forms, printing, viewing, simple logic are the kind of [operations] performed on a browser rendered user interface. The technologies can be HTML, CSS, JavaScript, Angular, JavaFX, GTK, Qt,…
Middle Tier
Moving to the Middle Tier. In the J2EE world, we can also think of this as the J2EE Business Layer. Traditionally, this has 2 main layers — hosted in the web container and the application container (EJB container). Additionally, a layer with the purpose of accessing data can exist, usually called the Data Access Layer. Here, once again we can appreciate the difference between layers and tiers.
The web container or web layer will hold the web rendering components of the application. You may also visualize it as a different physical deployment on a web server. The examples of technologies in this layer and container are JSP, Servlet, Struts (MVC), JAX-RS (REST), JAX-WS (SOAP), Spring (MVC), ASP.NET, PHP,…
The EJB container can be visualized as the Core Application or Business Logic Container of any application. This is an independent layer of deployment. Even though in the below diagram it is mentioned as EJB Container, You may call it as the Application Container or Service Layer or Business Layer. All the Brain/Heart/Logic of an Application will always lie in this Layer — Loosely, this can be termed as the Application itself. Its primary functions include interacting with Databases, Processing Business Logic, and sending data/objects to the Web Container. Examples of technologies in this layer and container are EJB, Spring (Remoting/POJO), [Windows Service*], Core Java (POJO),…
You must understand that the Service Layer need not always be an Application Server — It might be that a web technology such as JAX-RS (REST), JAX-WS (SOAP) may be used for this purpose.
(About Figure: Three-Tier (3-Tier) with Layer Separation into Web and EJB Containers, Note that the Web Container will render UI and EJB Container will Process Business Logic and Access Database)
Database Tier
Moving to the Database Tier or EIS Tier. This may also be referred to as the Database Server or Database Layer. The purpose is clear and easily deduced from the naming — it is used to store the data — for the purpose of this book, you may visualize it as RDBMS or Database. The database may have various schemas, tables that store the application data. Some of the flavors of RDBMS are Oracle, MySQL, PostgreSQL, DB2, … You must note some authors may call this EIS Tier (Enterprise Information Services Tier). You must understand that data may not always reside in an RDBMS — it may exist in a NoSQL DB, other Web Services (Data Sources), Streaming Data Sources, Connected Devices, Unstructured Data, File Systems, or any other form of data that is required to be accessed/processed by an application. The Database Tier is usually accessed from the Middle Tier.
In the next article in this series, we will discuss and dig into the disadvantages of Monolithic Architecture, one by one. Also, we will try to briefly present the possible remedial measures or better alternatives.
If you’re interested in Microservices Architecture, you may want to consider purchasing my book [Microservices Architecture, Booklet #01: The Decision Maker]. It is a must-read for all Decision Makers involved in Microservices Adoption or in a transition from Monolithic to Microservices Architecture. The ideal audience is CEOs/CTOs, VPs, Directors, Architects, and managers who are currently working or plan to work in these areas.
Buy on Amazon Prime: https://rebrand.ly/skp-msa-tdm-amazon-prime
Buy on Flipkart India: https://rebrand.ly/skp-msa-tdm-flipkart-india
Buy from Notion Press: https://rebrand.ly/skp-msa-tdm-notion-press
(Use Exclusive Coupon Code at Checkout on Notion Press, SKPXEBIA)
