Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

O'Reilly SA: Complex event flows in distributed systems

802 views

Published on

Talk held at O'Reilly Software Architecture Conference London together with @martinschimak on 16th of October 2017. It is about how to tackle complex event flows in distributed systems (which could be e.g. event-driven microservices).

Code from live hacking example is here: https://github.com/flowing/flowing-retail

Published in: Technology

O'Reilly SA: Complex event flows in distributed systems

  1. 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. 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. 3. Example Checkout Payment Inventory Shipping
  4. 4. Distributed systems
  5. 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. 6. End-to-end capabilities using event flows? InventoryPayment ShippingCheckout Order placed Payment received Goods fetched Goods shipped
  7. 7. Shipping Goods shipped End-to-end capabilities using event flows? InventoryPaymentCheckout Order placed Payment received Goods fetched Please fetch the goods before waiting for payment Some customers can pay via invoice …
  8. 8. Some requirements don‘t fit anywhere… What are we missing? Checkout Payment Inventory Shipping
  9. 9. InventoryPayment ShippingCheckout 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. 10. Commanding is important! InventoryPayment ShippingCheckout 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. 11. Some things in life take time
  12. 12. A customer can update an expired credit card within two weeks before we cancel his order „
  13. 13. Payment requires state handling Order
  14. 14. Pass around state as „routing slip“ Persist state with Entity, Actor, … State machine How to implement? DIY DIY
  15. 15. State machine Persistent thing (Entity, Actor, …) Routing slip CADENCE Baker
  16. 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. 17. Distributed systems
  18. 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. 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. 20. Do you need a timeout?
  21. 21. Do you need a compensation?*
  22. 22. BPM?
  23. 23. Flows done right Developer friendly Lightweight & composable BizDevOps
  24. 24. More complex flows - transparent and directly executable
  25. 25. Focus on long-running behaviour - requiring state
  26. 26. Specifying and testing long-running behaviour
  27. 27. A visual test report for example #1 (Balance = 50, Amount = 70)
  28. 28. A visual test report for example #3 (Balance = 50, Amount = 30)
  29. 29. The binding strategy uses the step only when required
  30. 30. Living documentation for long-running behaviour
  31. 31. Flows done right Developer friendly Lightweight & composable BizDevOps
  32. 32. Payment Flows are owned by services Order Distributed orchestration
  33. 33. 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
  34. 34. Example InventoryPaymentOrder ShippingCheckout Monitor https://github.com/flowing/flowing-retail/
  35. 35. Live hacking
  36. 36. Operational visibility in monitoring – possibly end-to-end
  37. 37. Mitigate tight coupling Consider core capabilities Leverage state machines Decentralize
  38. 38. Thank you!
  39. 39. 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
  40. 40. Images licensed from iStock no attribution required All icons licensed from Noun Project no attribution required

×