Microservice

Introduce microservice including the following items:
* Domain driven design
* event-driven architecture
* Saga pattern
* CQRS
* Event sourcing

Transcript

1. Microservice 17 Media Viney Shih, Sr. Engineering Manager
4. Agenda • What’s Microservice and the relation with organization • What’s the challenge moving to Microservice • Distributed data • Event-driven messaging • Consistency • Summary • Q&A
5. What’s Microservice
6. When to Microservice
7. Reference: https://andrebartholomeufernandes.com/why- software-is-eating-the-world/ In the future, every company will become a software company
8. Deliver software rapidly, frequently and reliably • Velocity • Lead time: time from commit to deploy • Deployment frequency: deploys per developer per day • Reliability • Change failure rate: % of deployments that cause an outage • Mean time to recover from a deployment failure
9. Needs to able to easily modernize applications • Successful applications often lives a very long time • Technology changes
10. Success Triangle Deliver changes to long-lived applications rapidly, frequently and reliably Process Architecture Organization
11. Success Triangle Deliver changes to long-lived applications rapidly, frequently and reliably Process: SRE, CI / CD, Automation Architecture: ??? Organization: Autonomous team
12. • SRE (DevOps) • Autonomous team • Long-lived applications Required architectural quality attributes (.a.k.a ilities) • Testability • Deployability • Maintainability • Modularity • Evolvability
13. Monolithic architecture
14. Ilities of small monoliths • Testability ✅ • Deployability ✅ • Maintainability ✅ • Modularity ✅ • Evolvability ✅
15. But when keep growing … Development Team Application
16. Keep growing … Application Development Team
17. Keep growing … Development Team Application Development Team Development Team
18. Reference: http://www.laputan.org/pub/foote/mud.pdf
20. Rapid, frequent and reliable delivery eventually becomes impossible Maintainability Testability Deployability Modularity Evolvability Time (Size complexity) Ilities required to be competitive Risk of disruption
22. The Scale Cube Reference: https://akfpartners.com/growth-blog/scale-cube
23. Y axis scale
24. X-Z axis scale Main Structure Replica set
25. Homework • What’s X-Y axis scale? • What’s X-Y-Z axis scale?
26. The microservice architecture is an architectural style that structures an application as a set of loosely coupled services
27. Each Microservice is • Highly maintainable and testable • Loosely coupled (e.g. database) • Independently deployable • Organized around business capabilities • Owned by a small team
28. Order Service Customer Service Product Service Notification Service
29. Benefits of Microservice Deliver changes to long-lived applications rapidly, frequently and reliably Process: SRE, CI / CD, Automation Architecture: microservice Organization: Small, Cross-function, autonomous teams Testability Deployability Maintainability Modularity Evolvability Modularity
30. Drawbacks of microservice: Complexity • Development: IPC, consistency, partial failure, distributed data • Testing: integration, end to end, … • Infra: monitoring, deploy, … • Correctly identifying service boundaries → bounded context • Refactoring a monolithic application to a microservice architecture
31. Challenge I: How to apply it into domain model? • Object points to one to another. Order *Customer Address City Street OrderItem Quantity *Product Customer CreditLimit Product Price Name
32. Challenge II: How to implement ACID transaction? BEGIN TRANSACTION … SELECT OrderTotal FROM Orders WHERE CustomerID = ? … SELECT CreditLimit FROM Customers WHERE CustomerID = ? … INSERT INTO Orders … … COMMIT TRANSACTION
34. Domain-Driven Design (.a.k.a DDD) • Entity • Value Object • Services • Repositories • Aggregates
35. Aggregate • Cluster of objects that can be treated as a unit • Graph consisting of a root entity and one or more other entities and value objects.
36. Aggregate (cont.)
37. Aggregate: rule #1 • Reference other aggregate roots via identity. • Domain model → collection of loosely connected aggregates Order customerID Address City Street OrderItem Quantity productID Customer CreditLimit Product Price Name
38. Aggregate: rule #2 • Process one command by one aggregate. • Aggregate scope = Transaction scope → Service Order customerID Address City Street OrderItem Quantity productID Customer CreditLimit Product Price Name Order Service Customer Service Product Service
39. Aggregate granularity • If an update must be atomic, it must be handled by a single aggregate. • Granularity leads different consistency and scalability Customer Order Product Customer Order Product Order Customer Product Consistency Scalability
40. Two-Phase Commit (.a.k.a 2PC) is not a viable option • Guarantees consistency • Not supported by many NoSQL and MQ • Impacts availability in CAP Theorem • …
41. SAGA pattern from a 1987 paper
42. How do the saga participants communicate? • Synchronous (e.g. REST, gRPC, …) • Availability(N) = Availability(N1) x Availability(N2) x Availability(N3) x … • Recovering mechanism: retry Order Service Customer Service createOrder() POST /order reseveCredit() PUT /customer/id/credit
43. • Collaboration using asynchronous, broker-based messaging • eventual consistency • At least once delivery • Ordered delivery • Availability(N) = Availability(N1) Order Service Customer Service createOrder() POST /order reseveCredit() Message Broker
44. Two patterns • Choreography: distributed decision making • Orchestration: centralized decision making
45. Choreography-based Saga Status: Pending / Created / Rejected DB
46. Choreography-based Saga (cont.)
47. Benefits and drawbacks of Choreography • Benefits • Simple • Participants are loosely coupled • Drawbacks • Decentralized implement: difficult to understand • Cyclic dependencies • …
48. Orchestration-based Saga
49. Orchestration-based Saga (cont.)
50. Benefits and drawbacks of Orchestration • Benefits • Centralized coordination logic is easier to understand • Reduce cyclic dependencies • Simplified the business logic • Drawbacks • smart orchestrator tells dumb services what to do
51. Homework • Synchronous RESTful API initiates asynchronous SAGA • Rollback strategy • SAGAs are ACD → No Isolation
52. How atomically update database and publish an event? • Dual write problem Service Database Message Broker ❓ ❓
53. Data consistency in event-driven architecture • Application events (Transactional outbox): • eBay • one transaction two tables, and one app polling
54. • Transaction log tailing: • LinkedIn • polling transaction log • MySQL binlog • Postgres WAL • AWS DynamoDB table streams • MongoDB change streams
55. • Event Sourcing: • Persists an object as a sequence of events View id: 123 author: Jane Doe impact: 10
56. Benefits and drawbacks of Event Sourcing • Benefits • Solve data consistency • Preserve history → replay whole data • Support temporal queries • Simplify retroactive correction • Built-in auditing • Drawbacks • Unfamiliar programming model • Evolving the schema of long-lived events • Only supports PK-based access → CQRS
57. Command and Query Responsibility Segregation (.a.k.a CQRS) • Using events to update a queryable replica.
58. Summary • Microservice enables whole business, team and architecture • Data is distributed which create challenges • Use event-driven architecture for eventual consistency • Use Sagas to maintain data consistency across service • Understand Event Sourcing and CQRS
59. Q & A Thanks for your Time!