What is Microservices
-
Bigger project is broken into independent modules/processes(called microservice) running on independent VM or Docker
container. Size of microservices can vary from 100 LOC to 10k.
Microservices are stateless because new MS boots in to serve existing request, it should not care about states.
Advatanges of Microservices
-
1. Independent deployble modules: All teams can work independently of each other. Teams can make their own technology decisions.
2. Adopting New Technology: Developers can employ a completely new technology stack (without affecting the others).
3. Easy replacement: Complete microservice can be re-engineered or replaced easily, without affecting other microservices
4. Resilience: If 1 microservice of a system fails, failure will not cascade to rest of the system. Rest of system can carry on working.
5. Scaling: Each microservice can be scaled independently.
Disadvatanges of Microservices
-
1. Increased Operation effort: MS system have many more units wrt deployment monolith hence requires larger operations efforts
2. Increased Latency: MS communicate over network, hence will take more time wrt file based communication.
3. Testing all microservice together: if 1 microservice is broken, it will break whole system.
Deployment Monolith
-
All components are integrated into a single codebase.
Advantages of Monolith
-
1. Simplicity in Development: With everything in one place, development is often faster and simpler, making it easier for new team members to onboard
2. Ease of Deployment: Deploying a monolithic application involves managing fewer moving parts
3. Simplified Testing: all components are part of a single unit, allowing for efficient end-to-end testing without complex inter-service communication
4. Low Latency: Since all components run within the same process, IPC takes less time.
Disadvantages of Monolith
-
1. Scalability Challenges: If 1 module need more resources, entire application must be scaled up, since other modules might not function with new resource, this leads to unneccessary time wastage.
2. Slower Development Speed: Dev1 working on part1, dev2 on part2. Integration testing might need more time. dev1 might use lib1 and dev2 lib2
3. Technology Constraints: challenging to adopt new technologies or frameworks without significant rework
4. High Dependency Risks: An issue in one component can affect the entire application’s functionality.
Situations where monolithic is suitable
-
1. Startups and Small Teams: Small teams (2 to 5 members), a monolithic architecture allows for faster development and deployment
2. Proof of Concept Development: Creating MVP(Minimum Viable Product)
3. Simple Non-Scalable Application: If application has simple functionality and does not have complexity or scalability demands
4. Min Latency required: Spacecraft system. A delay of microseconds b/w component communication is not acceptable
5. Less Operational Complexity: For systems which need less Operational complexity, monolith is preferred.
Microservice vs Deployment Monolith
| Microservice | Monolith | |
|---|---|---|
| CI/CD pipeline | Smaller | Huge. Time taken to execute CI/CD is big. Machine needed to build CI/CD should be high end |
| Debugging | Easy. Memory leak in MS will crash MS only | Hard. Memory leak in monolith will crash whole system & hard to debug |
| Communication | network. Add latency | files, IPC |
| Stateless | Yes | No. Modules will be tightly coupled |
| security | More. since all MS are isolated from each other | |
| delivery to Market | Fast | slow |
| Complexity | Small code, easy to understand | Huge code, tough to correlate |
| Database | Each should have its own DB or atleast its own DB schema. | Might use common |
Microservices Design Patterns
- These are software patterns that create reusable, autonomous services
| Pattern Name | Description | Example |
|---|---|---|
| 1. API Gateway |
Single entry point for clients to access multiple microservices.
Client will hit APIs and rest of services sit behind API gateway. Useful for routing, authentication, rate limiting, and other cross-cutting concerns. |
Netflix |
| 2. Service Discovery Pattern | Enables a service client(such as an API gateway), to determine the network location of a service instance so that it can invoke it. | zookeeper |
| 3. Circuit Breaker Pattern | Service1 makes call to Service2. And Service2 is in failure state, instead of keep on trying again and again, Calls to Service2 are stopped after x attempts for n number of seconds. | SRX Config pushed to ConfigPusher and waiting for ACK |
| 4. Externalized Configuration | Configuration settings should be externalized from the codebase, allowing services to be more configurable without requiring redeployment. | ArgoCD manifests, Spring Cloud Config |
| 5. Event-Driven Architecture | Microservices can communicate asynchronously using events | Kafka producer consumer |
| 6. Saga Pattern | A DB transaction is broken into smaller transactions & each transaction is handled by seperate service. |
e-commerce order. Reserve the product. Charge the customer’s card. Reduce the stock Ship the product |
| 7. CQRS (Command Query Responsibility Segregation) |
Responsibility of quering data and handling/processing data is handled by different components This pattern splits the responsibility of handling commands from retrieving data. |
e-commerce platforms |
