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 St 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.
Moving from Monolithic to Microservices
This article tries to
provide a sequence of steps to move from monolithic to microservices
architecture. An architect or technical stakeholder can use this as a guideline
reference for their microservices strategy planning. It tries to cover the
functions of research & development, product/application development, devops,
testing, engineering management (agile, demos) and product management (demos,
prioritization). We also try to cover the code branching strategy briefly. This
articles revisits (from earlier articles in this series) the
challenges of moving from monolithic to microservices.
At the end, the article will provide a series of
checklists (excel) to be used in your application/product development.
Remember that this article may also help your organization for a go/no-go
decision on microservices. As a technical decision maker, you should be able to
bold enough to make a decision against microservices - if you have ascertained
that after your research & survey. It is not mandatory that every piece of
software be written using microservices! Also, be open to consider hybrid, other
software architeture forms or find in place solutions to the problems faced by
your application.
Understanding the Existing 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 standardized example of a 3-tier monolithic architecture. Most enterprise systems prior to the microservices world would have chosen a 3-tier for their implementation.
As the sub-heading suggest, one of the most important steps in moving to a microservices architecture is to understand the existing monolithic architecture. It is very important that the architect / technical decision maker has the knowledge of the product / enterprise software architecture of the existing system. The various contexts to understand the existing architecture include the following :
- Core Functionalities / Core Features
- Non-Core or Supporting Features
- Major Issues Faced by the Application
- Performance Reports - Load & Stress
- Understand the Database Design
- Identify Business Entities & Objects
- Additional Resources - Messaging,...
- Vision of Management for
the Future
The idea is that the product features (core & non-core), performance, stability, scalability, business/domain entities or objects should be known to you to a certain extent before you decide on the microservices strategy. Only if you have a decent enough knowledge depth of the application in each of these contexts - you may be able to make the right decisions.
Challenges of Moving to 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 exists 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.
Identify Monolithic Services to Move to Microservices
Core Features - Scalability
The Technical Stakeholder first needs to identify the core features that are candidate for scalability. As the success of a business might entirely depend on the scalability and success of its core features, this becomes one of the candidate in the business context as well. Also, most of the hardware of software resources' consumption will be by the core features. The most used features are almost always the core features. There might be services that fall into any of the above categories but are not scalable enough, especially at very high loads. In earlier architectural paradigms, It was required to scale the entire set of features - Now we can only identify the ones that meet our criteria and transform them to scale them independently.
Core Features - Stability
Almost always in a Software Application, some features or services maybe a painpoint in the context of stability. Few times these might be the core features. Now, without considering whether the instability is related to database, messaging, filesystem, external events, streaming data, poor programming, poor design, memory leaks or any such other reasons - These services become a candidate to be moved to Microservices Architecture. Here, the idea is not to conceal Inadequacy under Microservices - But to use Microservices either until the Issues are Fixed or just because the Services are 'unstable or unresponsive' at times due to the external dependencies of such services.
Performance Requirements
After the consideration of core features for scalability or stability, the Architect or Stakeholder has to enlist or note the features that have very strict performance requirements. Usually, the constraints were met while they were in a monolithic block - Either due to entropy or as a result of increased loads, recently there might be a notable deterioriation in their performance. With Microservices, now exists an opportunity to easily meet or exceed the Non-Functional Requirements or Performance Requirements.
Independent Scaling
There might be services existing in the Application that require Independent Scaling - This might be due to heavy database or such other resource usage. They may either be core or non-core features. Sometimes these features may be asynchronous or batch processes. All of these may qualify as Independently Scalable.
Independent Maintenance
Sometimes due to geographic distribution of domain knowledge, technical teams, support teams - The maintenance of parts of application will easily become a candidate for movement to Microservices. Now, this may also just simply because the company envisions a service to be Independently Maintenable as the tools or technologies are very niche and can be either maintained by external or internal specialist teams.
Independent Development
With Greenfield or Scratch Development, this becomes the most important candidate for Microservices - Independent Development across geographic teams, technical skill, domain competency are the reasons why the Microservices Architecture provides flexibility in development.
Research on Microservices Architecture
Literature Survey
Since Microservices is still a newer paradigm all over the world - Most Architects or Stakeholder(s) might be recently introduced to this topic. It is required that a good amount of literature survey is done by the Engineer in this regard to collect all relevant blueprint(s), standardized architecture diagram(s), design patterns, reference implementations, books/online books on the matter are referenced to come up with the Organizational Strategy.
Case Studies
As a subset of the above, but still requiring separate mention is a collection of case studies - that will allow the Architect to identify the Pitfalls, Failures and Shortcomings of Microservices as well as to revisit all shortcomings of the Monolithic Architecture. To learn from other mistakes also is a great advantage and allows the Architect to correlate the current situation to one of the other failed or successful case.
Understanding Microservices
Time has to be spent on understanding the essence of microservices and also the needs on why it was introduced and is popular in Software Development. This includes the Needs, Motivations and Advantages of Microservices (Refer my Earlier Article)
Applicability of Microservices
Applicability is one of the most important thing from the development perspective - either from a Technical or a Business Perspective. As the Architect might be well versed with the Product Architecture, Business and Technical Requirements - he needs to carefully and correctly understand the applicability within his context. By identifying and catching issues early, the Architect will save a lot of effort, pain and money for the Organization.
Microservices Design Patterns
Knowing the standardized Microservices Design Patterns beforehand or as and when faced with the issues is one of the important steps that an Architect must take to solve the problems faced using one of the generalized patterns or solutions. The pattern may be related to Database, Messaging, API, Security, Creation of Microservices.
Reference Implementation of Microservices Infrastructure
So, Almost 3 articles that were entirely dedicated to
the Theory, Philosophy and Pragmatism of adopting Microservices. I bet every bit
of experience and education that i have got, that each and every section of
these articles will be Appreciated by the Architect or the Technical Decision
Maker. Now, Here we are with some Energetic and Exciting News! The Reference
Implementation - The Outcome of the entire series of these articles is in Obelix
- A Reference Implementation for Microservices. It will be made available
publicly on GitHub for any Student, Professional, Architect, Scientist to
download and use in their Projects/Products.
[Microservices Readiness & Certification]
It is recommended that once the Architect or
Technical Stakeholder is done with the Understanding the Microservices
Architecture and is ready to start off the Implementation, he needs to also plan
fo Microservices Readiness & Certification. The Idea of Readiness is to
understand that whether the organization or product is ready to adopt
microservices. Also, It includes a verification to find out if the organization
really understands that Microservices is really applicable for their use case or
needs. It should not be that since Microservices that is the new fad, It is
being adopted by the organization. Also, once the architecture has been laid out
- It needs to be certified as meeting the needs of the organization. It is not
necessary to be meeting all standard components or guidelines, but it is very
important that what has been proposed is what is required and can be sustained
by the organization or product. In other words, we need to identify areas to
improve and learn from them.
The best way to complete
the Microservices Readiness Survey/Test, Microservices Applicability Survey/Test
and Microservices Architecture Assessment Certification is to
involve internal or external stakeholder(s). If the organization can spend
budget on an external expert consultant to liasion with the Architect or
internal stakeholder - It may yield great review outcomes and improve quality of
the outcomes of the Architecture/Surveys. But If there are budgetary and
other organizational constraints, another way is to have internal stakholder(s)
who are Senior Technical Resources/Stakeholder(s) (Other
Architects, Lead Engineers, Engineering Managers, QA Managers*, Product
Managers*, Senior Management* : * - Optional) to form a
Review Committee in the organization to prepare Surveys/Tests/Checklists and/or
use online resources such as the one available at
https://microservices.io/platform/
to evaluate themselves. Remember, the Implementation of Microservices might be
'very easy', if most Architectural and Implementation Issues can be foreseen and
understood correctly.
[Obelix, Our Reference Implementation]
As mentioned earlier, the outcome of these articles is Obelix, The Microservices Reference Implementation. It is intended to be used directly in your applications (Especially Java/Java EE). It will try to provide a complete Microservice Infrastructure in terms of API Gateway, Circuit Breaker, Service Discovery, Config Server, Load Balancing Strategy, Config Server Bus Refresh, Messaging, Design Patterns, Service Mesh*, Docker*, Security, Sessions, Tokens, Data Access, K8s*, Maven, GitHub*, AWS*, Logging, Auditing and any Log Analysis. It may also act as the Architectual Basis for your ongoing Infrastructure or Product Development. The best suggested use will be to fork from the main branch for your Individual or Organizational needs. Oh! By the Way, I always consider Microservices a Mammoth Effort that makes many of the Ongoing Enterprise Needs Easy - So, Remembering One of my Favorite Cartoon Character Obelix from The Adventures of Asterix.
Code Branching Strategy for Microservices Architecture
Organizational Code Branching
The Architect has to plan for the Code Branching Strategy in Tandem with DevOps and other Stakeholder(s). It is very important the Initial Planning also contains the Code Branching Strategy. One of the most important is to make sure that all parts of development such as Reference Implementation, Product Development, Feature Development and any Research & Development (Experimentation) is branched out. Merging from the Research Branches for all development branches should be planned based on Major Releases or Milestones. Also, there may be times that Research branches are much ahead than that can be used by Product Development or even that the Experimentation branches might deemed as [Not to be Merged] with the development branches.
Reference Implementation
The Reference Implementation Branch will be the one that every organization should create as part of their Initial Microservices Strategy. This will hold all the Infrastructure, PoC, Prototype for Product Development - Any code to demonstrate the use of Microservices Infrastructural Services as also the usage of Messaging, Containerization, Load Balancers, Mesh, Security, Logging, Auditing should all be placed here. Also, the Prototype or PoC for the general usage of developers should be placed here. There should also be a reference or usage guide along with videos (optional) that should allow Engineering Managers and Engineers to understand the use of the Microservices Reference Implementation Architecture. This is that one point of reference that is going to be the driving force in your entire Microservices Strategy. The Architect needs to plan for Releases and continuously mature the Reference Implementation. The core idea is that a Company's Strategic/Core Research team be made owners of the reference implementation branch. This should also be the branch where Architecture Validation Testing can be done, be it Functional or Non-Functional.
Product Development
The main consumers of the Reference Implementation or
Microservices Architecture are the Product Development. In an IT Services
environment, they may be known as the Application Development team. In any case,
the Product Development Repository if already existing should be created afresh
for the Purposes of Microservices based Product Development. Here, any of the
Microservices Design Patterns may be used for the purposes of conversion of all
existing Product Development APIs to the Microservices Architecture. The Product
Development will have its own version of the Reference Implementation, just
because there might be a reason for the Product Development to have some tie-up
with the Reference Implementation - This may be in Configuration, Declaration,
Code (!) or Deployment. The owners of the Product Development may be the
Engineering Team.
At Release Times from the Reference Implementation
branch, that may be decided by the Strategic Team in Tandem with Product
Development Team, the code will have to be Merged in the Product Development
branches. Most of the Merge will be Auto Merge except when conflict arises due
to the specific product related changes. During this time, some collaboration
may be required between the two teams.
Feature Development
Only in very certain cases, Specific Feature Development may be focused or disparate from the Product Development Repository. In these cases, the same process as above may have to be used in Feature Development. In normal circumstances, Feature Development is always branched from Product Development.
Next Gen Experimentation
Apart from all of these, Some organizations may have ongoing NextGen Product Architectures or ongoing Newer Product Development. During this time, a Baseline Microservices Reference Implementation Architecture may suffice for all Experimentation. Usually, the Initial phases of such development are purely for Experimentation around Business Logic, Newer Frameworks, Newer Technology, Newer UI/UX or Performance/Security Enhancements. In this case, the Merge may not be required at the frequent releases of the Reference Implementation, unless ofcourse the outcome depends on the Microservices Reference Implementation.
The above explanation is done for a Typical Product Development Organization - The Architect or Technical Stakeholder(s) can apply the Strategy based on their Organization's unique needs. But it is one very important part of the Microservices Strategy, to decide on Code Branching/Merging.
Rolling Out Microservices to Development (Dev Team)
Typical Real-World Checklist for Microservices Strategy (Planning Phase)
Provided Below is a Real-World Checklist for Microservices Strategy - This was from a successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Lead Engineers, Engineering Directors*, Product Managers*, Senior Management*.
Typical Real World Checklist for Strategic Execution (Research Phase)
Provided Below is a Real-World Checklist for Microservices Execution in the Research Phase - This was from a Successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Engineers, Engineering Directors*. Few of the Tasks provided here can be considered as [Other Technical Activities Aligned to Microservices].
Artifact 2 : Typical Real-World Checklist for Microservices Strategy Execution (Research Phase)
Planning for Cloud and Containerization (DevOps Team)
The Planning for the DevOps Team Typical Revolves around the decisions on the below topics that should involve a DevOps Lead who under the guidance of a Principal Software Architect along with Engineering Managers, Lead Engineers and Senior Management will arrive at consensus.
- Choice of Cloud Providers
- No-Code and Low-Code
- Native Cloud Usage
- AWS*, Docker and K8s
- ECR, ECS, EKS, K8s//EC2
Provided Below is a Real-World Comparison for Microservices using Spring Boot Stack versus Native Cloud (AWS). This was from a Successful execution of Microservices Strategy in a Product/Project using Spring Boot+ Stack on Amazon Web Services using ECR/ECS. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads.
|
AMAZON WEB SERVICES / CLOUD
|
SPRING BOOT OR CLOUD / JAVA
|
EASE OF USE
|
DevOps Should be Fine to Use
|
Easy as Java/J2EE - Spring Boot
|
LEARNING CURVE
|
DevOps is Fine, Dev Can be Steep
|
Is Gentle, All of It is Java / J2EE
|
DOCUMENTATION
|
DevOps is Fine, Dev Blogs Maybe Less
|
Documentation, Blogs will be High
|
MAINTENANCE
|
May Reduce Number of Servers
|
Multiple Server(s) May Exist for Roles
|
LICENCE / COST
|
Most of It will Require Payment
|
Almost Always, Will be Free
|
OPEN SOURCE
|
Not All of It is Open Source*
|
All of It is Open Source*
|
VENDOR LOCK-IN
|
Locked-In to AWS Ecosystem
|
Move Anywhere / No Lock-In
|
INTEGRATION EASE
|
Might be Simpler within Ecosystem
|
Will be Fine Across Ecosystems
|
SKILL AVAILABILITY
|
Tough to Get AWS API Skill
|
Easier to Get Spring Boot Skill
|
EXTENSIONS/INTEGRATION
|
Tougher to Write Extensions
|
Extensive Help to Integrate
|
MICROSERVICES CONCERNS
|
May Not Be Available to Extend Easily
|
Complete Microservices Architecture
|
PERFORMANCE
|
Possibly, Marginally Higher
|
Possibly, Marginally Lower
|
SECURITY
|
Possibly, Marginally Better
|
Possibly, Marginally Lower
|
SCALABILITY
|
Should be Highly Scalable, By Itself
|
Will be Almost Equivalent Scalable
|
MONITORING
|
Tools for Easier Monitoring/Logging
|
Might Need to Indirectly Hookup
|
TOOLS IN ECOSYSTEM
|
May Not Be Available to Extend Easily
|
Complete Microservices Architecture
|
COMPANIES USING
|
[Unable to Gather Information]
|
[Unable to Gather Information]
|
DEVOPS / DEVELOPMENT
|
DevOps Skill and Experience
|
Developer Skill & Experience
|
LINKS TO JUSTIFY
|
-
|
-
|
Artifact 3 : Planning for Cloud and Containerization (DevOps Team)
Microservices Architecture Validation (Testing Team)
Architecture Validation
Testing
The Architecture Validation or Testing Architecture is required for any continuously evolving architecture. Now, Microservices by itself is a very Heavyweight Infrastructural Piece and it will undergo frequent updations as newer components are added, existing components are updated and any implementation context is changed between declarative, configuration and code. It is important that QA has a plan to test for the Architecture which includes a simple way to verify components like API Gateway, Circuit Breaker, Discovery Server and so on for positive and negative cases. So, By automating the architecture validation we are making sure of quality and sustained quality of the product. You need to put the tools to good ues, that available in your context or organization for the purpose of this automation. The discussion is beyond the scope of this article and I leave it as exercise for the reader. Please do leave your thoughts as comments to this article. Some articles related to DevOps and Testing Software Architecture and Testing Software Architecture might be good as starting points to read further on various ways to Test the Software Architecture.
Architecture
Validation - Performance
Testing
Just like Architecture Validation for 'Functional' aspects is very important - Dedicated or Automated Performance Testing for various components of the Architecture (and of the Architecture itself) is Very Important. At times, the Performance may deviate from the baseline performance set for Architecture Validation Testing, due to the changes in the components. This may catch the culprit changes early on and will be very helpful for the sanity of the Product Development Testing.
Planning for Microservices Testing
The Software Architecture of a Product will undergo Architecture Erosion - Term used to denote frequent changes and its Impact on the stability and performance of the Architecture. It is very important that during the time of the Microservices Strategy Planning (or atleast when the Most Important Phases of the Research are Complete) that the Microservices Architecture Testing is planned for. During this time, the Testing (QA) team should also be educated on what the Needs, Meaning and Motivations of the Microservices Architecture are.
Sample Tasks for Research & Development (Agile Sprints/Demos)
Sample High-Level Roadmap for Microservices
Provided Below is a Real-World High Level Task List for
Microservices Roadmap for Senior Management/Stakeholder(s) to Adapt their
Strategy from - This was from a Successful execution of Microservices Strategy
in a Product/Project. The Copyright/Proprietary Information (If Any) has been
Removed from the Provided Table. This is actually created by a Principal
Software Architect with contributions from Engineering Managers, DevOps Leads,
Engineers, Engineering Directors*. Few of the Tasks provided here can be
considered as [Other Technical Activities Aligned to Microservices].
Artifact 4 : Sample High Level Roadmap for Microservices
Sample High-Level Milestone List for Microservices
Provided Below is a Real-World High Level Task List for Microservices Milestone List for Senior Management/Stakeholder(s) to Adapt their Strategy/Planning from - This was from a Successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Engineers, Engineering Directors*. Few of the Tasks provided here can be considered as [Other Technical Activities Aligned to Microservices].
Artifact 5 : Sample High Level Milestone List for Microservices
Sample High-Level Sequential Demos for Microservices
Provided Below is a Real-World High Level Task List for Microservices Demos List for Senior Management/Stakeholder(s) to Adapt their Strategy/Planning/Tasks from - This was from a Successful execution of Microservices Strategy in a Product/Project. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This is actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Engineers, Engineering Directors*. Few of the Tasks provided here can be considered as [Other Technical Activities Aligned to Microservices].
Artifact 6 : Sample High Level Milestone List for Microservices
Well, The Next Article in this Series will be the [Popular Microservices Design Patterns]. Until Then, Wishing you a Great Strategy Time using Microservices!
[Side Note/Copyright
Information]
Provided Tables and Lists are from a Real-World Microservices Strategy Execution in an Enterprise Java/Java EE Product. This was from a Successful execution of Microservices Strategy in a Product/Project using Spring Boot+ Stack on Amazon Web Services using ECR/ECS. The Copyright/Proprietary Information (If Any) has been Removed from the Provided Table. This was actually created by a Principal Software Architect with contributions from Engineering Managers, DevOps Leads, Lead Engineers, Product Managers*, Engineering Directors*, Senior Management*. It may turn out to be really useful to understand how the Real World Adoption goes on and can be planned for. Also, You may have your own context to add to the above Lists based on the Specifics of your Environment / Product.
No comments:
Post a Comment