SKP's Microservices #01 - The Pains of Monolithic Architecture

Intro 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.

 

 

FIG.1 : Typical Three-Tier Architecture
(Source : IBM, Available on Google Search)

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

Before we delve into the details of monolithic architecture, I think this will be an interesting topic to discuss. Tiers are physical separations of groups, of similar or dissimilar kind 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 either 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.

 

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 something that is Entirely on the Client or the End Visible User Interface of the Application. This will be 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, Application 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, Browser can be thought of as a Container). Mostly, the Simple Validations, Filling Forms, Printing, Viewing, Simple Logic is the Kind of [Operations] performed on a Browser Rendered User Interface. The Technologies can be HTML, CSS, Javascript, Angular, JavaFX, GTK, Qt,...

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.

 

FIG.2 : Typical J2EE Architecture (3-Tier with Layer Separation into Web and EJB Containers)

[Obtained 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 Application.

 

Disadvantages of Monolithic Architecture

 

Development

Monolithic Systems were built by a Single Focussed Team that maybe Geographically Dispersed - Mostly the Concerns of the Architecture, Layer Wise or Feature Wise Might be the way Development Teams of Varying Specialities are Organized. Most of the Times, these Teams will be on the Same Broad Skill Set or Technology Stack. Now, Although this is Correct - It Does Not Truly Allow a Team to Completely Concentrate on a Problem or a Feature (In-Whole). Also, There is a Chance in the Same Organization People of Different Skills or Technologies might want to Come Together in an Organization to Build the Application Features or Components. Each of them may want to Layer their Individual Components to their Own Specific Needs/Ecosystem. This was not Possibe with Monolithic Systems.

Coupling

The Systems built with the Monolithic Thought Process are More Tightly Coupled Across Layers or Across Components - Since they Reside on the Same 'Server Function' most of the Times - Services or Components are More Tightly Coupled. Even though by Building with Correct SOLID and OOPs Paradigms - They may Still Be Considered to be More Tightly Coupled as a Result of Being Packaged in the Same Binary. 

 

Scalability

Monolithic Systems, especially those ones with lots of Non Functional Requirements related to Performance and also Scalability. These Systems are usually marred by Symmetric Scalability but this will lead to System Resources being shared between the Services that do not have Scalability Requirements and ones that have Scalability Requirements. Usually Systems Need Asymmetric Scalability wherein the Core Features or Core Business Logic Services May Have Higher Scalability Requirements and the Helper or Non-Core Features might be Have Very Less Hardware or Memory Requirements.

Availability

Now the Availability Needs to be Thought as a Different Technical Requirement Different from Others - With Monolithic Systems, If a Server Comes Down - Almost Always, the Entire Application Stops Responding - Even If it is Highly Available, There maybe times at Peak Load - The System Stops Responding or Slows Down to the Point that the Application is Actually Unavailable.

Performance

Performance in the Monolithic World will have to be Planned for the Entire Application. This also Includes Performance Testing. Just as Described Earlier - The Parts of the System that are Severe Load might actually cause the Entire System to Slow Down. Though this Point is Very Similar to the Scalability Point - You always have to Note that the Performance of a System or API will have to be Accounted Separately from the Scalability. Though the Same Reasons Apply, It has to be thought of as a Localized or in a API Specific Notion.

Infrastructure

Monolithic Systems - Though, In Existence from almost the Advent of Software Engineering - Never Had Some Standardized Infrastructure Components - Even Though with the Advent of SOA, Few of the Infrastructural Components started Finding their Place in Software Architecture - Most of the time Infrastructural Abilities for Service Availability, Failure Recovery, Configuration Management, Service Health, Service Discovery, Security Infrastructure, Messaging Mechanisms, Logging, Log Analysis, [Many More Concerns] where mostly Built or Incorporate in a Very Custom Way Per Project or Product.

Business

Well, the Most Important Outcome of Engineering is almost always that the Innovation or the Product is More Easily Available or Sellable to the Market. The Greatest Advantage is that Business <> Engineering Bridge is More Complicated or May Need More Time to Deliver On in the Case of Monolithic Architecture. Also, the Product is almost always thought as a Complete Unit and will be Sold as a Subscription or Fixed Price or Pay as you Go Mechanism. Usually, when a Customer wants only a Few of the Services or Features, Business Teams would Bundle It up - But Under the Hood the Product would Still Be One Large Unit of Code/Binary.

 

 

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 RDBMS/Database.

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

 

FIG.3 : Visualization of Monolithic vs Microservices (Software Architectures) 

(Image Rights with Knoldus Blogs)

 

 

Promise of Microservices for Development Teams

With the Advent of Microservices, The New Promise of Truly Allowing Development Teams to Focus on their Specific Components or Services Irrespective of the Technology Stack, Layering (Specific Architecture), It's Own Database (Not Just Schema) - This Allows Global Teams Now to Concentrate on their Development without the Need to Co-ordinate with Other Teams except for Common Components, Interaction Mechanism or Infrastructure Services.

Promise of Microservices for More Independence

With Microservices, Each of the Services can be Made Truly Independent of Each Other and thereby Really 'Loosely Coupled'. They will be Deployed on Disparate Servers and Can Now Even be Considered to be Built with any Technology that is the Expertise of the Company/Unit.

Promise of Microservices for Scalability

With the Advent of Microservices, One of the Greatest Advantages is that it allows us to Architect/Design Systems that can Scale Independently at Every Level - Whether it is Service Level or at the Database Level or any Resource that may otherwise have been Shared. This will allow us to Plan and Size for Systems Accurately and More (Cost-) Effectively. The Organization will get (almost) Every Worth of their Penny through Accurate Sizing/Scaling Excercises. The Resources will be Allocated and Used as the Actual Customer Usage Reflects in the Budgeting. Although the Challenges Introduced Now by Communication Mechanisms within Microservices or Distributed Database Transaction Mechanism may Result in Negative Outcomes. The Performance and Scalability of Microservices will be Discussed in Detail in my Future Articles in this Series.

Promise of Microservices for Avaialability

In the Micorservices World, the Independent Nature of Services Now Allows us to Plan for High Availability Much Easier and Fault Tolerance, Failure Recovery, Retry on Fail Mechanism are Now More Automated and Efficient. Also, The Failure of a Single Service will Never Bring the Entire Application Down. For Mission Critical Systems, this is a Great Advantage as Parts of Systems or Features will Keep Responding even though Few Services Have Failed in the Ecosystem.

Promise of Microservices for Performance

In Theory, The Performance of Microservices should ideally be Greater than the Same Monolithic Service since the Application/Feature will now have its own Server, Database and Resources - But Since the Microservices have a Lot of Infrastructural Services and the Communication Overhead may Result in a Negative Outcome. This Topic will be Discussed Further in my Future Articles - For Now, You have to Simply Note that If a Monolithic Service were to be Built on a Database Per Microservice Kind of Architecture, It is Bound to Perform much Higher than it's Monolithic Counterpart.

Promise of Microservices for Infrastructure

With Microservices, Mostly there is a Widely Agreed Upon Standardized Architecture that is a Master Blueprint for Organizations to Follow for their Microservices Architecture. Even If Companies were to Adopt/Implement only Partial Infrastructural Component from the Said Standard - It will still mean that there is Uniformity in the Way Microservices are Implemented. There are many [Make or Built] of the Actual Infrastructural Frameworks that are Available for these Standardized Requirements. The Organization or the Microservices Architect may use any of them, Based on the Suitability to their Environment.

Promise of Microservices for Business

Inherently, with Microservices Architecture - The Business Advantage is the ability to Independently Sell/Size the Services and the Associated Hardware or Resources for a Customer. Now, the Business can Plan for Subscription, Pay As You Go, Fixed Price at a Service Level Much 'Easily'. Also, Any New Service or Even Custom Services can be Easily Planned, Independently Built and Incorporated into the Entire Product Ecosystem at a Customer or Product Level.

FIG.4 : Microservices - The Reigning Champion (Already?) In the War of Software Architectures
(Image Rights with Thoughtworks)

 

Well, The Next Article in this Series will be [The Needs and Motivations for Microservices]. Until Then, Wishing you an Inquisitive Time with Microservices!