Microservice architecture design principles
- 2. Let’s take the inspiration from biological cells before talking about Microservice: • They are small and single purpose • They are many of them but they work in concert with one another • Each cell is able to respond to its environment • They communicate with each other using messages • They can replicate • They keep outside out • Death is natural and expected
- 3. Microservice architecture advocates creating a system from a collection of small, isolated services, each of which owns their data, and is independently isolated, scalable and resilient to failure.
- 4. Divide and Conquer A divide and conquer algorithm works by recursively breaking down a problem into two or more sub-problems of the same (or related) type (divide), until these become simple enough to be solved directly (conquer). The solutions to the sub-problems are then combined to give a solution to the original problem.
- 5. In Microservice Architecture we use Divide and Conquer: the decomposition of the system into discrete and isolated subsystems communicating over well-defined protocols.
- 6. Microservice Single Responsibility Replaceable Organized around business capabilities
- 7. Single Responsibility Principle Single Responsibility Principle (SRP) states that a class or component should “only have one reason to change.”
- 8. Do One Thing, and Do It Well This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. —Doug McIlroy
- 9. “Micro” should refer to scope of responsibility. A service has only one single reason to exist and should provide a single composable piece of functionality.
- 10. A service should do one thing and do it well. Focus should be on business capability.
- 11. What about state? Microservices are often stateful entities: they encapsulate state and behavior.
- 12. Product Service Customer Service Order Service Payment Service Search Service DB This is still a monolith.
- 13. Oracle Couchbase Oracle Customer Service Customer Service Customer Service Customer Service Product Service Product Service Product Service Product Service Order Service Order Service Order Service Bounded Context Bounded Context Bounded Context A microservice owns its data. Business Capability Business Capability Business Capability
- 14. Decentralized Data Management • Each microservice manages it’s own database: either different instances of same database technology or completely different database system (polyglot persistence) • Eventual consistency
- 15. Microservices encapsulate state and behaviour. Model each service as a Bounded Context. Each service usually defines its own domain, each with its own Ubiquitous Language. State (Data) Behaviour (Business Rules) Business Capability
- 16. Search Service Search Service Search Cache Couchbase Product Service Product Service Product Service Product Service Bounded Context Bounded Context Client Business Capability Business Capability
- 17. Isolation Isolation is a prerequisite for resilience and elasticity Embrace Share Nothing Architecture Failure Isolation (Bulkheading) Isolation between services makes it natural to adopt Continuous Delivery Isolation also makes it easier to scale each service, as well as allowing them to be monitored, debugged and tested independently Isolation is a prerequisite for autonomy
- 18. An autonomous service can only promise its own behaviour by publishing its protocol/API. All information needed to resolve a conflict or to repair under failure scenarios are available within the service itself, removing the need for communication and coordination. APIs need to be well-defined and composable. Autonomous Service
- 19. Communicate through APIs Service B Couchbase Service A Oracle API invoke expose Contract Shared understanding
- 20. API Client/Server Guidelines REST level-3 with HAL+json Use proper HTTP techniques Base design on application states and transitions Forward compatibility over versioning Drive documentation from code Don’t write smart clients
- 21. Autonomy through Messaging Service A (Pub) Service B (Sub) Service C (Sub) Message Bus1 2 3
- 22. • Only publish business events and IDs – avoid mutable data • Implement proper error handling • Beware of added complexity Message Publisher Guidelines
- 23. • Cater for duplicate message delivery through idempotency • Don’t rely on ordering • 1C late-commit pattern over 2PC • Implement proper error handling • Beware of added complexity Message Receiver Guidelines
- 24. Microservice benefits • Strong module boundaries • Independent deployment • Technology diversity • Failure isolation • Improves time to market • Reduced cost of change and costs • Distribution • Eventual consistency • Operational complexity
- 25. General Microservice Architecture Principles • Small and focused on a specific business capability • Eventual consistency • availability is more important than global and instant consistency • Polyglot persistence • Pick most appropriate data and consistency model • Async communication over sync • Failure resilient • Avoid SPOFs
- 26. Thank you