Introduction to SKP's Microservices Masterclass Series
SKP's Microservices Masterclass is a Series of Articles on Microservices Architecture (MSA) - Starting with the Needs and Motivations of Microservices, Moving to the Shortcomings of Monolithic Architecture and Also Covering Microservices Design Patterns, Pitfalls of Microservices, Major Microservices Infrastructure Components - Description, Evaluation and Code Samples, Containers, Native Microservices, Cloud Platforms, Messaging Layers, Security and Logging. We will Provide the Readers with Obelix, A Microservices Architecture Reference Implementation! You May Use this as the Starting Point for your Microservices Architecture. You may Also Directly Use this as a Reference Implementation for your Microservices Strategy and/or as Code to Learn and Implement the Microservices Architecture for your Organization.
Explanation of a Typical Monolithic Architecture
SKP's Microservices Masterclass - The Most Common
Software Architecture that One can Safely Say has been in Existence ever Since
Software Development Started - It 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 Article, We will use
the Most Common and Standarized Example of a 3-Tier Monolithic Architecture.
Most Enterprise Systems Prior to the Microservices World would have chosen a
3-Tier for their Implementation.
Tier vs Layer
This will be one Interesting Discussion to Take Up before we Delve into the Details of Monolithic Architecture. Tiers are Physical Separations of Groups of Similar Kind of Functionalities or Layers. For Example, the User Interface Renders on Browser - Hence, It Qualifies as a Broad Level Functionality (Physical) with a Specific Concern (Logical) - The Client Tier or Presentation Tier. Next, The Presentation Layer might Exist along with a Business Layer either each of them on a Web Server and Application Server repsectively or together on an Application Server - Hence, This Qualifies as Different Functionalities (Physical) having Similar Concern (Logical) - The Business Tier. Next, the Database Schema (Physical) will be on a Database Tier (Logical) which by itself is a Concern. Hence, You have to Note that Tier is Different from a Layer. Note that In Some Web Development Textbooks or in Practical Usage - The Web Layer might Actually be the First or One of the Tiers among the 3 Tiers in this Architecture. The User Interface will be rendered on the Client Tier by this Presentation Layer. So, Presentation Layer Prepares the User Interface for Rendering based on the Data that is Returned from the Application Layer which actually Fetches it from the Database Layer. With this Introduction, You are clear that Tier is a Logical Grouping of Related Physical Layers. Tiers are Logical Units whereas Layers have Physical Presence.
FIG.1 : Typical Three-Tier Architecture (Source : IBM, Available on Google Search)
Let us Now Get Into a Detailed Explanation of Each
Important Tier in the 3-Tier Architecture.
Moving to the Application Tier. In the
J2EE World, we can also think of this as the J2EE Application Server Layer.
Traditionally, this has 2 Main Layers - the Web Container and the
Application Container (EJB Container). Here 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 just call it as the Application Container or Application Layer or Business Layer. All the Brain/Heart/Logic of an Application will always lie in this Layer - This can actually be termed as the Application Itself. It's Primary Functions include to Interact with Database, Process Business Logic and Send 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 have to Understand that the Application 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.
from Google Search]
(Note that the Web Container will Render UI and EJB Container will Process Business Logic and Access Database)
Moving to the Data Tier. This may be
Referred to as the Database Server
or Data Layer. The Purpose is clear and easily deduced
from the Naming - It is used to store the Data - For the Purpose of this
Article, You may visualize it as RDBMS or Database. The Database may have
various Schemas, Tables that store the Application Data. Some of the Flavours of
RDBMS are Oracle, MySQL, PostgreSQL, DB2, ... You have to Note Some Authors may
call this EIS Tier (Enterprise Information Services Tier) - Also, Note that Data
may not always Reside in a RDBMS - It may be NoSQL, Other Web Services (Data
Sources), Streaming Data Sources, Connected Devices, Unstructured Data, File
Systems or any Other Form of Data that may Need to be Accessed/Processed by an
Disadvantages of Monolithic Architecture
Database - The Albatross Around the Architect's Neck
We Need to Discuss this Topic in Detail as this is the
One cause the Much Performance, Scalability, Stability (Reliability),
Availability Issues Many a Times in the Enterprise Software Development World.
One of the Primary Motivations or Outcomes of a Microservices Architecture by
Providing a Database Per Service Architecture. Most of the Times, an Architect
is given the arduous Task of Meeting, Delivering and Exceeding Not only the
Functional Requirements but also the Non-Functional Requirements. Now, when we
speak of the Non-Functional Requirements we can Talk of Performance,
Scalability, Stability and Availability in One Breath. Even though they
are related, they all usually need to be Handled Separately. Most of the Time,
these Issues have One is to One Correlation with the Database Performance and
Scalability. If Not with the Database, they may have to do with Data Access
Layers of the Application. Also Note when we Simply Mention Database Here we
mean RDBMS. Most Enterprise Applications and Products are Built on
For Almost Every Request to an Application, The Database is that one Critical Resource Decides The Performance. As the Load (Number of Requests), The Database Can Deteriorate the Performance - Also, In Effect the Increase on an Application Reduces the Performance for Each Request or Query to a Point that the Application Response Time may become Unacceptable. This is Termed as the Scalability of the Application (or the Database). Once the Requests Exceed a Given Threshold, the Application May Become Unstable and there might be Requests that either are Served Very Slowly or Not Served at All. Even though Measures Exist to Put this in Check, the Number of Active Requests may Increase to such an Extent that the Application or Database Becomes Unavailable or Involuntarily Terminates. So, The Entire Effort in Application Architecture and Design Now are Focussed to Make Sure that Application Meets the Performance, Scalability, Stability and Availability Based Non-Functional Requirements. The Point that is Being Tried to be Driven Across is that Database is One Resource which is almost always the One that is the Biggest Bottleneck to Meet these Requirements. Even with Adequate Functional, Load, Stress or Soak Test - The Application may Fail while In Real-World Production Environments.
With the Above Discussion, It is clear that More Often than Not - Database or RDBMS Becomes the Albatross Around the Software Architect's Neck - The Single Point of Concern that May Even Decide the Success of an Application, Product or Business!
The Promise of Microservices Architecture
Monolithic vs Microservices (Software Architectures)
(Image Rights with Knoldus Blogs)