Saturday, July 10, 2021

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

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

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.

 

 

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.


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 [Moving from Monolithic to Microservices Architecture]. Until Then, Wishing you an Inquisitive Time with Microservi
ces!

Friday, July 2, 2021

SKP's Microservices #2 - The Needs and Motivations for Microservices

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.


Types (Evolution) of Software Architectures

Well, The Textbook of Software Architecture may want to classify the Types and Evolution of Software Architectures into Mulltiple Types and Sub-Types. But for all Practical Purposes, these four will be the Most Important Types of the Software Architecture that a modern day Software Architect may be able to identify. Almost all Modern Enterprise and Software Product Architecture can be classified into the following :

FIG.1 : EVOLUTION OF SOFTWARE ARCHITECTURES (IMAGE IS OBTAINED FROM GOOGLE SEARCH)


  1. Monolithic Software Architecture

    As the name suggests, Monolithic Architecture is Virtually a Single Block of Components to Serve all the Application Requests. It is one of the forms that has existed ever since Software Development and Software Engineering came into the world. It may be Distributed or Non-Distributed Application. Usually, In a Monolith the Implementation consists of Various Layers to achieve the functionalities as per the Application Requirements. Even though it may have few Asynchronous Components or Functionalities - For All Purposes, You can Imagine to be a Monolithic Block or Centralized Block, Consisting of Various Layers to Achieve the End Goal. Few Types of Monolithic Architecture are 2-Tier, 3-Tier or N-Tier Applications. You may Read more Specifically on Mononlithic Architectures from this Microsoft Link.

  2. Service Oriented Architecture (SOA)

    Service Oriented Architecture took the Thought Process of Software Architecture to a More Decentralized, Loosely Coupled Interactions Between Components to Serve the Application Requests. Mostly, the Initial Thoughts in SOA were for Disparate Enterprise Systems Interacting through a Shared Interaction Mechanism called as the Enterprise Bus. Service Oriented Architectures can be thought as a Coarse Grained Decentralization of Components to Achieve the End Goal. Service Oriented Architecture was Bulk, Heavyweight but was Able to Serve the Purpose of a Co-ordinating Set of Services/Systems (Possibly Monolithic Themselves).

  3. Microservices Architecture (MSA)

    The Architecture that is the State of the Art and has Caught on to Almost all Enterprises and every Medium to Large Software Development Project - Microservices Architecture (MSA). The Core Thought Involves True Decentralization of the Services or the Application and More Fine Grained Splitting or Division of Application Services into Individual Services of their Own. Also, MSA brings in a Newer and Complex Form of Infrastructural Services to Aid in the Real Ownership of Respective Infrastructural Responsibility. Though, It has it's own Set of Disadvantages (Will be Discussed Later in this Series of Articles) - It allows for Independent Scaling and 'Selling' of Services to a Customer or any External Stakeholder.


    FIG.2 : DETAILED VISUALIZATION OF LAYER WISE/FUNCTION WISE FOR MONOLITH vs. MICROSERVICES vs. SERVERLESS
    (IMAGE CREDITS TO XENONSTACK)


 

Shortcomings of the Monolithic Systems (Promise of Microservices 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.

Promise of Microservices
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.

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.

Promise of Microservices
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.

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.

Promise of Microservices
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.

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.

Promise of Microservices
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.

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.

Promise of Microservices
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.

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.

Promise of Microservices
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.

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.

Promise of Microservices
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.3 :  FEATURES/CHARACTERISTICS OF EACH TYPE OF ARCHITECTURE (CREDITS TO www.rubygarage.org - OBTAINED FROM GOOGLE SEARCH)

The Above Image Shows the Features of Each Type of Software Architecture and the Most Important Grade of Companies or Applications that they are Suitable For. Our Focus in this Article in on the Details of Shortcomings of Monolithic Systems (As the Most Important or Prevalent Type of Software Architecture in Use Before Microservices) - As of Today, In 2021, Companies are in a Mad Fervor to Move Completely to Microservices or Hybrid Varities of Microservices.


Challenges of Microservices Architecture

Overhead
The Setup of Microservices Requires More Efforts as there a Lot of Infrastructural Architectural Pieces as part of a Complete Microservices Architecture. For Example - API Gateway, Circuit Breaker, Discovery Server, Config Server, Health Monitoring, Vault Service, Token Service, Logging & Auditing - These are Just a Few of the Initial Infrastructural Services Required to Correctly Implement a Complete Microservices Architecture in the Enterprise.


High Skill
There is a High Skill Level Require Especially in Terms of Experienced Senior Architects, DevOps and Developers who can Now Understand the Change in Development Paradigm. Also, This May Either Increase the Development Time or Development Costs or Both.


Complexity
One of The Most Important Disadvantages of Microservices is the Complexity Involved. Even Though the Point is Captured in the Above 2 Points - It Still Requires a Mention on its Own. The Interplay of the Plethora of Infrastructural Services along with the Actual Application Microservices may Create Unending Cycle(s) of Complexity.


Redundancy
During Development, the Architects and Lead Engineers may Need to Keep a Watch on Making Sure that there is No Duplication of Code, Configuration or any other Effort that may Already have been Developed by Another Team. This Starts Becoming a Greater Concern when there are Geographically Distributed Teams and Focussing Entirely on their Own Set of Business or Product Deliverables. Though some very Trivial Code Duplication may be Inevitable as far as Possible - Discipline will be Required to Isolate and Group Common Functionality or Code Together Correctly.


Data Duplication
One of the Greatest Challenge is Data Duplication. Most Inexperienced Architects and Engineers may end up in Such Situations. It is because the Thought that was required to Build Monolith Data Access and Creation cannot Now be used for Microservices. The Mechanism to Maintain Data Integrity and Data Consistency in a Product to Make Sure that There Exits a Correct 'Single Version of Truth' Needs to be Planned, Architected and Infused into the Design.


Communication
The Communication Between External World and Microservices or within Microservices may Fail. This could be Due to Multiple Reasons Including Network Failure and Service Unavailability. In any Case, The Communication Between Microservices is Critical and is Tough to Setup and Maintain. It also Requires Constant Monitoring of Health and Performance of Each of the Microservices. Partial Failures is actually an Advantage of Microservices - But Still the Monitoring, Failure Detection, Failure Handling and Simply the Internal/External Communication can be Quite an Overhead in the Implementation of Microservices.


Maintenance
So, Once the Initial Part is Over - Even If the Microservices Strategy and Implementation Turns out to be a Success - It still Means a Heavy Hit on the Pocket for Maintenance. Even though all of the Current Generation Organizations Rely on an External Cloud Provider, It Still Means More Expenditure on Hardware, 'Software', Cloud, DevOps Engineers. Also, the Total Cost of Ownership of Such an Infrastructural Masterpiece is Only Bound to Increase as More Abstractions are Added Over Time - Also, The Maintenance Itself could be a Complicated Process.


True Cloud Applications and Containerization

AWS, GCP, Azure and More
At the turn of the Decade (2010s), Came the Dawn of the True Cloud Native Applications - Most Popular of the Cloud Providers Being Amazon Web Servics, Microsoft Azure, Google Cloud Platform. The Paradigm of Deployment Now Moved from a On-Premise, Hosted to a Public Cloud or Private Cloud. Now, Microservices that Slowly caught on Speed by around 2015s and The Adoption has Never Stopped Since. As of 2021. Almost 50%* of the World's Application Being Built using the Microservices Architecture (Either Entirely, Partially or Hybrid) - Now True Cloud Native Applications and Microservices are Not Exactly an Equivalent - But the Cloud Providers are Able to Provide Most of the Infrastructure in their Own Ecosystem. So, We can Say the True Cloud Native Environments have Ready Support for Microservices Infrastructure and Architecture.


Docker, Kubernetes and ++
Docker and Kubernetes and Any Other Container Technology Tools are a Modern Day Enhanced Equivalent of a Web Server or Application Server, except that the Function is to Now Vendor Neutrally Deploy Images and Allow Multiple DevOps Functions to be Carried Out on the Images - Such as Configuration, Clustering or Communication. Docker and Kubernetes have Become the Gold Standard for Enterprise Software - With Docker Being Popular for Containerization and Kubernetes for Container Orchestration. Now, Docker and Kubernetes will Allow Monolithic Architecture to be Deployed as Welll - But the Containerization Paradigm has a One is to One Correlation with Microservices as Both Allow an Independent Nature of DevOps and when Combined with True Cloud Providers - They Become the Modern Day Development & Operations Engine for  Deployment, Maintenance, Containerization, Cloud, Scalability, Availability, Failure Recovery, Configuration, Communication and More Infrastructural Concerns. 



The State of Microservices in 2021

As of 2021, As a Principal Software Architect in the Software Industry - Being Part of Almost 4 Companies that Have Adopted or Started to Adopt Microservices (Especially Using Spring Boot, Spring Cloud, Spring Data, Spring Security, Netflix OSS as Java/Java EE Stack is my Area of Expertise) - I can now Safely say that almost all Companies have either Moved to or In the Process of Moving to Microservices. This is Due to the Obvious Advantages and Promises of Microservices. Every Technology in History has Brought with it a Newer Set of Problems whcih Engineers and Architects have Solved in their Newer Counterparts. Neverthless, Microservices is one such Engineering Innovation. In the Future Articles in this Series, We shall Look at the Issues that are Faced by Microservices Themselves, In Detail. The Below Categorization Clearly Shows that Microservices and its Hybrid Varities are Slowly Displacing Monolithic and SOA Architectures in the Enterprise and in Software Development Projects.

The Only Word of Caution would Remain for Architects, Decision Makers and Organizations is to Make Well Researched and Reasoned Out Decisions. Microservices should not simply be thought as a Silver Bullet for Every Problem that a Product or a Service is Facing. Alternative or Hybrid Ways should also be Considered. Various Considerations like Budget, Maintenance Costs, Resources, Skill Availability, Vision, Timelines, Current Ecosystem among Others shoould be thoroughly Understood and Justified before an Organization Takes a Plunge to Microservices. Even though Microservices Holds Promise to Solve a Lot of Issues that Marred Monolithic Architecture, Few Organizations and Architects Do Not Totally Agree with the Advantages that Microservices have to Offer. It also remains to be Seen if the MSA will again Evolve (Converge or Diverge) into Much Simpler or Even Complicated Architecture Types of the Future.



FIG.4 :  THE 2021 STATE OF MICROSERVICES REPORT (CREDITS TO www.jrebel.org - OBTAINED FROM GOOGLE SEARCH)

 

Well, The Next Article in this Series will be the [The Pains of the Monolithic Architecture]. Until Then, Wishing you a Fulfiling Time with Microservices!