⭐ Microservice pattern is an architecture that functionally decomposes an application into a set of services. It doesn’t say anything about size. Each service has focused, cohesive set of responsibility.
Characterstics of Microservice architecture
- X, Y and Z-Axis Scalability of micro services (Michael Fisher’s book - The Art of Scalability (Addison-Wesley, 2015) - Scale cube)
- Microservices as a form of modularity
- Each service has its own database
How is this different from Service oriented architecture (SOA)?
- In SOA, smart pipes as Enterprise Services Bus (ESB) using heavyweight protocols like SOAP, while Microservices has Dumb pipes as a message broker, or direct service to service communication using REST or gRPC.
- In SOA, data is global and shared, in MS database per service
- SOA is a typical large monolith.
Benefits of Microservices
- continuous delivery and deployment
- small services easy to maintain
- independently deployable
- independently scalable
- enables team to be autonomous
- allows experimenting and adoption of new tech
- better fault isolation
Challenges with Microservices
- Finding right set of services
- Distributed systems are complex, makes dev, test and deployment difficult
- deploying fetures that span multiple services required carefult coordination
- hard to know that when to adopt MS acrhitecture
When to use (or not use) Microservices
- If it is working then don’t change it
- MS is not a silver bullet
Microservices Architecture Pattern Language
It is a collection of patterns that help you:
- architect your application
- decide whether to use microservice architecture or not
- use it effectively by solving various architecture and design issues.
📚 Christopher Alexender - A Pattern Language: Town, Buildings, Construction
📚 Erich Gamma, Richard Helm, Ralf Johnson and John Vlissides - Design Patterns: Elements of Reusable Object Oriented Software
A Pattern is reusable solution to a problem that occurs in a particular context. Any repetable Pattern must describe the context in which that pattern is useful.
A commonly used pattern structure includes three especially valuable sections:
- Forces: What issues you must address when solving with the pattern
- Resulting Context: The consequences of applying the pattern
- Benefits: What issues (Forces) pattern is going to solve
- Drawback: which existing issues (forces) pattern doesn’t solve
- Issues: if it introduces few more issues
- Related Patterns:
- Predecessor: Monolith architecture is predecessor of Microservices Architecture
- Successor: A pattern which solves issues that has been introduced by current pattern
- Alternative: A pattern that provides an alternative solution to this pattern. Like Microservice is alternative to Monolith.
- Generaliztion: Any pattern which is a general solution to a common problem,
- Specializaton: A pattern which solves a special problem. Like container patter is specialization of single service per host.
Patterns broadly can be divided into following three categories:
- Infrastructure Patterns: solve problems that are mostly outside of development.
- Application Infrastructure Patterns: Infrastructure issues that also impact development
- Application Patterns: These solve problems faced by developers.
Main Groups of patterns
- Decompose by business capability
- Decompose by subdomain
- Communication style
- Transactional messaging
- External API
- Message prpcess gurantee
Data consistency Patterns for Transaction management
Patterns for querying the data in MS architecture (CQRS)
Service deployment patterns
Observability patterns provide insight into app behaviour
- Health check API
- Log aggregation
- Distributed tracing
- Exception tracking
- Application metrics
- Audit logging
Patterns for automated testing
- Consumer-driven contract test: Verify that service meets expectations of its clients
- consumer-side contract test: verify tat the client of a service can communicate with the service
- Service componen test: test a service in isolation
Pattern for handling cross cutting concerns (database, Kafka related reusable concerns)
📚 Fred Brooks: The Mythical Man-Month
👉 Move fast without breaking things.
- Deployment frequency
- Lead time
- Mean time to recover
- Change failure rate
- Ending, Losing and Letting Go
- The Neutral zone
- New beginning