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 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.
Microservices Architecture : Moving from Monolithic to Microservices
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 architecture 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.
Fig. 1 : Obelix
- The Microservices Reference Implementation (SKP's Microservices Masterclass
Series)
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*.
Artifact 1 : Typical Real-World Checklist for Microservices Strategy (Planning Phase)
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 [Failures, Pitfalls & Disadvantages of Microservices]. 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.
