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)
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.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).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!
No comments:
Post a Comment