O'Reilly London 2017: Complex Event Flows in Distributed Systems

O'Reilly Architecture 2017, London, United Kingdom

Transcript

1. Complex event flows in distributed systems O‘Reilly Software Architecture Conference 16th of October 2017 mail@bernd-ruecker.com martin.schimak@plexiti.com With thoughts from http://flowing.io @berndruecker | @martinschimak
2. Bernd Rücker Consultant & Dev. Advocate 10+ years workflow Co-founder Camunda http://bernd-ruecker.com/ Martin Schimak Consultant & Trainer 15+ years domain (de-)coding DDDesign, TDD/BDD, EDA http://plexiti.com/ http://flowing.io/
3. Example Checkout Payment Inventory Shipping
4. Distributed systems
5. Event-Driven Checkout Payment Inventory Shipping Bus Order Placed Does not know recipient Does not know sender Decentral data management Smart endpoints and dumb pipes Event: Fact that happened in the past, Immutable fact, 0..n recepients Order Placed Customer status changed Does know event type…
6. End-to-end capabilities using event flows? Inventory Payment Shipping Checkout Order placed Payment received Goods fetched Goods shipped
7. Shipping Goods shipped End-to-end capabilities using event flows? Inventory Payment Checkout Order placed Payment received Goods fetched Please fetch the goods while waiting for payment Some customers can pay via invoice …
8. Some requirements don‘t fit anywhere… What are we missing? Checkout Payment Inventory Shipping
9. Inventory Payment Shipping Checkout Bus Order Order Placed Retrieve Payment Order Placed Event: Fact, happened in the past, immutable, 0..n recepients Let‘s make our core capability transparent – as a dedicated service Command: Intent, 1 recipient.
10. Commanding is important! Inventory Payment Shipping Checkout Bus Order Placed Event: Fact, happened in the past, immutable, 0..n recepients Retrieve Payment Command: Intent, 1 recipient. Fetch Goods Ship Goods Order Order Placed Retrieve Payment Does not know sender Just knows command type… Dangerous?
11. Some things in life take time
12. A customer can update an expired credit card within two weeks before we cancel his order „
13. Payment requires state handling Order
14. Pass around state as „routing slip“ Persist state with Entity, Actor, … State machine How to implement? DIY DIY
15. State machine Persistent thing (Entity, Actor, …) Routing slip CADENCE Baker
16. State machines solve some hard developer problems Monitoring & Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
17. Distributed systems
18. State machines solve some hard developer problems Monitoring & Operations Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
19. Bpmn.createProcess("order").executable() //... .sendTask().name("Retrieve payment").camundaClass(RetrievePayme .receiveTask().name("Payment received").message("PaymentReceive //... { "name": "retrieve_payment", "tasks": [ { "name": "Retrieve Payment", "taskReferenceName": "payment", "type": "SIMPLE", ... Do you prefer coded or graphical DSLs? * BPMN - ISO notation for modeling and executing long-running processes and flows
20. Do you need a timeout?
21. Do you need a compensation?*
22. BPM?
23. Flows done right Developer friendly Lightweight & composable BizDevOps
26. More complex flows - transparent and directly executable
27. Focus on long-running behaviour - requiring state
28. Specifying and testing long-running behaviour
29. A visual test report for example #1 (Balance = 50, Amount = 70)
30. A visual test report for example #3 (Balance = 50, Amount = 30)
31. The binding strategy uses the step only when required
32. Living documentation for long-running behaviour
33. Flows done right Developer friendly Lightweight & composable BizDevOps
34. Payment Flows are owned by services Order Distributed orchestration
35. Order Order Order Order Architecture Order Engine A Payment Engine B Monitoring Human Task Management Coarse grained central monitoring Fine grained monitoring & operations (per context) DevOps Tec Ops Biz Ops Central
36. Example Inventory Payment Order Shipping Checkout Monitor https://github.com/flowing/flowing-retail/
37. Live hacking
38. Operational visibility in monitoring – possibly end-to-end
39. Mitigate tight coupling Consider core capabilities Leverage state machines Decentralize
40. Thank you!
41. Code online: https://github.com/flowing Slides & Blog: https://bernd-ruecker.com https://plexiti.com With thoughts from http://flowing.io @berndruecker | @martinschimak https://www.infoq.com /articles/microservice- event-choreographies