Migrating from Monolithic Architecture to Microservices Hands-On Real-World Case Study
In this article and the attached video, I will go through a real-world experience that I have done to migrate from Monolithic architecture to Microservices. This will be a hands-on video
What is a Monolith?
“Monolith” You might have been hearing this word a lot, recently, or its other synonym “Monolithic Architecture”. It is a scenario when a company depends on one service or database and it becomes a bottleneck. At this time, the need to decompose this monolith into microservices becomes a necessity. In the following short clip, I explained what is a Monolithic Architecture:
All the details are explained on the slides that I presented to the Board of Investors:
https://rany.tk/static/MonlithToMicroservices.pdf
1. The first slide explains the design goals
Design Goals
- Reduce time/cost to create new ways to use Community Data
- Reduce endpoints
- Improve performance
- Network efficiency
- Mobile and Web Client-friendly interface
- No versioning
- Maintainability
- Resilient to changes
- Real-time usage (not necessary to have a separate cache layer)
- Domain-Driven Architecture
- One source of truth for managing communities
- Support all existing functionality of clients
- Extensible for new requirements
The problem that I was trying to solve:
Problem Statement
We are not able to fulfill the business needs due to the following issues
a. Monolith DB for all domain
b. Dependency on one DB and one team for all domains
c. Single point of failure
d. Separation of concerns
e. Single Responsibility
f. Explosion of endpoints, lack of documentation, slow performance
g. Separation of domains
h. Nonflexible design and not easily extendable without a re-write (PC — CC)
i. No separation between FE and BE
j. Upgrades and maintainability
Design Principles — The client should not need to know application-specific details to use the API
- The API will be the source of truth for Community Data used by all APFM applications
- Single responsibility for API, only works with communities
- Open for addition, closed for modification
- Should support progressive migration of data out of YGL
- API should be loosely coupled with other systems
- Should be fault tolerant and can scale automatically
- Should support consumer-facing web workloads
- Design for availability and partition tolerance and eventually consistent
- Support concurrency
- Should be secure, with authentication and authorization
- Role-based filtering of data
- It should be cost efficient
- It should contain logging and instrumentation
- Network efficiency, one call, minimize client aggregation and processing of data
- It should be easy or automatically documented, should be discoverable
- It should be testable by engineers
Domain Driven Design
First, I have done event storming and derived the domains using a Domain Driven approach.
The API Gateway Pattern
Given the previous requirements, I had 2 choices about APIs (GraphQL vs RESTful APIs) [Slide 10]
The second choice was between serverless vs containers:
[Slide 11]
The Proof Of Concept
Finally, I created the POC and demonstrated creating a microservice in front of investors, CTO, CEO, and directors.
Database replication and Migration Steps
Refer to this article for details
Progressive Data Migration
- Created the schema and decided on entities
2. The following article explains how we migrated from the monolith DB to the new databases.
References:
WRITTEN BY:
