Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

O'Reilly Architecture 2017, London, United Kingdom

2999fab21d182294fad0b2cc590fd54d?s=128

Martin Schimak

October 16, 2017
Tweet

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

  24. None
  25. None
  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