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

muCon London 2017: Break your event chains!

muCon London 2017: Break your event chains!

2999fab21d182294fad0b2cc590fd54d?s=128

Martin Schimak

November 06, 2017
Tweet

Transcript

  1. Break your event chains MuCon, November 6th 2017, London 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 Developer & Trainer, 10+ years (de-)coding domain knowledge DDDesign, TDD/BDD, EDA http://plexiti.com/ http://flowing.io/
  3. 3 common hypotheses we check today: # Events decrease coupling

    # Central control needs to be avoided # Workflow engines are painful
  4. None
  5. Simplified example: dash button Photo by 0xF2, available under Creative

    Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/29873149904/
  6. Three steps…

  7. Who is involved? Checkout Payment Inventory Shipment

  8. Basic idea of dedicated, autonomous (micro-) services Checkout Payment Inventory

    Shipment Dedicated Application Processes Dedicated Persistence Backends Dedicated Development Teams
  9. Events decrease coupling

  10. Request/Response: temporally coupled services Checkout Payment Inventory Shipment „The button

    blinks green if we can ship the item within 24 hours!“ Request Response
  11. Events: temporal decoupling with read models Checkout Payment Inventory Shipment

    „The button blinks green if we can ship the item within 24 hours!“ Events are facts about what happened (in the past) Good Fetched Good Stored Read Model
  12. Events: Extract cross-cutting aspects Checkout Payment Inventory Shipment „Inform the

    customer about steps he is interested in!“ Order placed Payment received Good shipped Notify me when … Order placed Payment received Good fetched Good shipped Customer Mailings Good fetched
  13. Events can decrease coupling* *e.g. decentral data-management, read models, extract

    cross-cutting aspects
  14. Events: peer-to-peer event choreographies Checkout Payment Inventory Shipment Order placed

    Payment received Good shipped „When the button is pressed, an order is placed - and fulfilled!“ Good fetched
  15. Events: peer-to-peer event choreographies Fetch the goods before retrieving the

    payment Some customers can pay via invoice … Checkout Payment Inventory Shipment Good fetched Order placed Payment received Good shipped
  16. Extract the end-to-end responsibility Order Checkout Payment Inventory Shipment Order

    placed Retrieve payment Commands have an intent about what needs to happen in the future Fetch the goods before retrieving the payment Some customers can pay via invoice Payment received Retrieve payment
  17. Events can increase coupling* *e.g. complex peer-to-peer event chains

  18. Commands can decrease coupling* *e.g. to avoid complex peer-to-peer event

    chains
  19. Central control needs to be avoided

  20. Checkout Payment Inventory Shipment Order Order placed Payment received Good

    fetched Good shipped Smart ESB-like middleware
  21. Checkout Payment Inventory Shipment Order Dumb pipes „Smart endpoints and

    dumb pipes!” Martin Fowler
  22. The danger of god services Checkout Payment Inventory Shipment Order

    „A few smart god services tell anemic CRUD services what to do!” Sam Newman „Central“ order service as bad as central ESB logic?
  23. A god service is only created with bad API design

    Checkout Payment Inventory Shipment Order „Smart endpoints and dumb pipes!” Martin Fowler Smart endpoints take care of a business capability their client does not need to understand.
  24. Ask: who is responsible to deal with problems? Order Credit

    Card Retrieve Payment Expired A single central client of dumb endpoints becomes a god service. Better: we create several decentral, smart endpoints. „If the credit card expired, the customer gets another chance to provide new card details!“
  25. Ask: who is responsible to deal with problems? Order Credit

    Card „If the credit card expired, the customer gets another chance to provide new card details!“ Expired „Smart endpoints are potentially long-running.” Payment Retrieve Payment Payment received „The client of a smart endpoint remains lean.”
  26. Be sceptical about central control!* *e.g. centralized ESB-like components or

    god services which heavily interact with dumb endpoints
  27. But don‘t give up control!* *e.g. miss to extract and

    control important potentially long-running business capabilities
  28. The problem is not to command services! The problem is

    bad API design.
  29. Workflow engines are painful

  30. Persist thing with Entity, Actor, … State machine or workflow

    engine DIY Order Credit Card Payment Payment received How to implement long- running services?
  31. State machines or workflow engines CADENCE Baker

  32. Workflow engines solve some hard developer problems Monitoring & Operations

    Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
  33. Distributed systems

  34. Workflow engines solve some hard developer problems Monitoring & Operations

    Handling of time & timeouts Retry Visibility & Reporting Versioning Compensation Message correlation & deduplication Performance & scalability
  35. Workflow and BPM

  36. None
  37. None
  38. 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
  39. Timeouts

  40. Compensation*

  41. Living documentation for long-running behaviour

  42. Focus on long-running behaviour - requiring state

  43. A visual HTML report for a specific test case

  44. Workflows live inside service boundaries

  45. Explicit flows help separate domain and infrastructure Infrastructure Aggregates, Domain

    Events, Domain Services, etc … + the flow Workflow Engine Payment Application Domain
  46. Lightweight workflow engines are great (and much better than DIY)*

    *e.g. enabling potentially long-running services, solving hard developer problems, can run decentralized
  47. Workflow engines can do (service) orchestration.* Orchestration is not about

    synchronous request/response! *We are not talking about container orchestration
  48. None
  49. # Events decrease coupling: sometimes read-models, no complex peer-to-peer event

    chains, don‘t forget commands # Central control needs to be avoided: sometimes no ESB, smart endpoints/dumb pipes, important capabilities need a home # Workflow engines are painful: some of them lightweight engines are easy to use and can run decentralized, they solve hard developer problems, don‘t DIY
  50. Need some code? Inventory Payment Order Shipping Checkout Monitor https://github.com/flowing/flowing-retail/

    Human Tasks
  51. Thank you!

  52. 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
  53. Images licensed from iStock no attribution required All icons licensed

    from Noun Project no attribution required Images licensed under Creative Commons license Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/2987 3149904/