Need to divide monolithic into microservices ,how and into how many microservices should it be done?
Dividing a monolithic application into microservices is a complex and strategic process. The goal is to create a system where each microservice handles a distinct business capability.
. Understand the Current Monolith
Analyze the Monolith: Map out the business logic, modules, and dependencies in the monolithic application.
Identify Boundaries: Look for logical boundaries (business domains, functionalities, or workflows) in the application. These could be modules, classes, or APIs.
Understand Bottlenecks: Identify pain points, such as performance bottlenecks, scaling challenges, or long deployment times, to prioritize services that need isolation.
2. Domain-Driven Design (DDD)
Use Domain-Driven Design (DDD) to identify bounded contexts in your application:
Bounded Contexts: Define business domains (e.g., User Management, Payment Processing, Inventory Management, etc.) and group related functionalities.
Entities and Aggregates: Within each context, identify the core entities and their relationships.
Example for an e-commerce system:
User Service: Handles user registration, authentication, and profiles.
Order Service: Manages orders, tracking, and fulfillment.
Payment Service: Handles payment processing and refunds.
Inventory Service: Tracks stock levels and updates.
Catalog Service: Manages product listings, prices, and categories.
3. Identify Microservices
Each microservice should:
Be loosely coupled with other services.
Have a single responsibility (aligned with business capabilities).
Be independently deployable and scalable.
Common Examples:
For an e-commerce application:
Authentication and Authorization: Handles login, user sessions, and permissions.
Product Catalog: Manages product data.
Cart Service: Tracks users' shopping carts.
Order Management: Manages orders, order statuses, and workflows.
Payment Service: Handles transactions and payment processing.
Inventory Service: Tracks product availability.
Notification Service: Sends emails, SMS, or push notifications.
Analytics Service: Tracks user interactions for reporting.
4. Divide Based on Business Capabilities
Use the business capability approach to identify services. Each capability can become a microservice. Examples:
Core Capabilities: Functions that are core to the business, such as processing orders or payments.
Supporting Capabilities: Functions like sending notifications or generating reports.
Consider Granularity:
Avoid creating too many small services, which increases communication overhead.
Avoid creating overly large services, which defeats the purpose of microservices.
5. Technical Factors to Consider
Database Design:
Each microservice should ideally own its data store.
Break the monolithic database into smaller, service-specific databases.
Use strategies like database per service or shared database with logical isolation during the transition.
Communication Between Services:
Decide on synchronous (e.g., REST, gRPC) or asynchronous (e.g., Kafka, RabbitMQ) communication.
Use API Gateway to route requests and manage APIs.
Data Consistency:
Use event-driven architectures to achieve eventual consistency across services.
6. Steps to Migrate
Prioritize Services to Migrate:
Start with a small, non-critical module to test the migration strategy.
Migrate modules that are causing the most pain points (e.g., scalability issues).
Refactor One Module at a Time:
Extract a module, build it as an independent service, and integrate it back into the system.
Use feature flags to test the microservice in production while still relying on the monolith.
Use Strangler Fig Pattern:
Slowly replace parts of the monolith with microservices, while keeping both systems running until the migration is complete.
Set Up Monitoring and Logging:
Use distributed tracing tools (e.g., Zipkin, Jaeger) to monitor service interactions.
Implement centralized logging (e.g., ELK stack) to debug issues.
Test Extensively:
Ensure functional, integration, and performance testing for each service.
7. How Many Microservices?
The exact number of microservices depends on:
Application Size: Large monoliths may result in dozens of microservices, while smaller applications may need only a few.
Business Complexity: Divide services based on business requirements and their complexity.
Team Structure: Follow the "two-pizza team" rule—each service should be small enough to be managed by a team of 2-5 people.
Example for E-commerce:
Small Scale: 3-5 microservices.
Medium Scale: 6-10 microservices (User, Catalog, Order, Payment, Cart, Notifications, etc.).
Large Scale: 10+ microservices with fine-grained domains (e.g., split Cart Service into Cart and Discount Services).
8. Challenges and Solutions
A. Challenges:
Data Dependencies: Breaking apart a shared database can be difficult.
Service Communication: Increased complexity due to network calls.
Deployment Overhead: Microservices require CI/CD pipelines for each service.
B. Solutions:
Use an event-driven architecture to handle cross-service communication.
Implement observability tools to monitor service health.
Use a service mesh (e.g., Istio, Linkerd) for managing communication, retries, and failures.
Conclusion
To divide a monolithic application into microservices:
Analyze the monolith and identify business domains.
Use Domain-Driven Design to define bounded contexts.
Start with high-impact modules and migrate incrementally.
Ensure proper communication, observability, and data separation between services.
The number of microservices depends on the application's size, business requirements, and team structure. Focus on creating a loosely coupled and highly cohesive system that meets the business goals while ensuring scalability, maintainability, and reliability.
source:-wikipedia