Know the flow! Events, commands and long-running services.

Know the flow! Events, commands and long-running services.

@martinschimak -> Oct 4th, 2018 -> Microservices Munich

2999fab21d182294fad0b2cc590fd54d?s=128

Martin Schimak

October 04, 2018
Tweet

Transcript

  1. Events, commands and long-running services Oct 4th, 2018 -> Munich

    -> Microservices Meetup Know the flow! @martinschimak
  2. Commands Events @martinschimak and Retrieve payment Payment retrieved

  3. vs Orchestration Choreography Long-running services

  4. Events look into the past „An event is something that

    has happened in the past.“ - Greg Young Payment retrieved @martinschimak
  5. Commands look into the future A command specifies something that

    should happen in the future. Retrieve payment @martinschimak
  6. Commands and events. And intent. „Commands are all about intent.

    - Jonas Bonér @martinschimak Events have no intent.“ Intent Retrieve payment Payment retrieved Outcome
  7. Commands and events. Like two sides of a coin? Payment

    retrieved Payment retrieval Intent Outcome Execution Something should happen Something happens Something happened Retrieve payment @martinschimak
  8. Order fulfillment Commands and events. Flipping the coin? Payment retrieved

    Outcome Execution Something happens Something happened @martinschimak Intent Something should happen Fetch goods
  9. Domain events are more explicitly discussed than commands @martinschimak

  10. Events are really simple to grasp ... Goods shipped Order

    placed Goods fetched Payment retrieved ... EventStorming! @martinschimak
  11. EventStorming! When it starts to get interesting! :-) @martinschimak

  12. Events to separate write and read models ... Order summary

    Payment retrieved Payment UI raises projected onto ... CQRS! @martinschimak
  13. Events to temporally decouple services ... Order summary Payment retrieved

    Payment UI raises projected onto Payment Service Order Service ... CQRS with „foreign“ events! @martinschimak
  14. Events to represent history and state of systems ... Payment

    received Payment Payment received Payment received Payment received Payment retrieved ... Event Sourcing! @martinschimak
  15. Events to enable whole business processes ... ... Event choreographies!

    Payment received Inform customer listened to by Payment Service Notification Service @martinschimak
  16. Let‘s just rely on events in between services! @martinschimak

  17. Payment Service Credit Card Gateway @martinschimak

  18. Item ordered My context of sophisticated fulfillments Energy traded Order

    fulfillment Energy trade execution Coverage extension requested Policy issuance @martinschimak
  19. plexiti.com @martinschimak

  20. Eric Evans, 2004

  21. 2004 2006 2008 2018 2010 2012 2014 2016 London Amsterdam

    Denver Berlin ? Vienna
  22. 2004 2006 2008 2018 2010 2012 2014 2016 ?

  23. New pair of shoes ordered End-to-end business processes and their

    phases New pair of shoes ordered Old pair of shoes worn out Order new pair of shoes New pair of shoes delivered Order Fulfillment History Customer-driven Supplier-driven Supplier-exploring Human to Machine Supporting Service Customer-determined Machine to Machine Automated Service @martinschimak
  24. A company‘s „long-running“ order fulfillment service Order new pair of

    shoes New pair of shoes delivered Domain Command Domain Event “Long-running” service Order fulfillment service Supplier-driven Customer-determined Machine to Machine Automated Service @martinschimak
  25. „Long-running“ services have long-running contracts Order new pair of shoes

    New pair of shoes delivered Order fulfillment service “Long-running” service “Long-running” asynchronous contract Hours to weeks @martinschimak Domain Command Domain Event
  26. „Long-running“ services may have internal customers Retrieve payment Payment retrieved

    Payment service “Long-running” service Seconds to weeks @martinschimak “Long-running” asynchronous contract Domain Command Domain Event
  27. „Long-running“ services with fine-grained contracts Charge credit card Credit card

    charged Credit card gateway “Long-running” service 1 to 20 seconds @martinschimak “Long-running” asynchronous contract Domain Command Domain Event
  28. Order Service Order placed Payment Service Payment retrieved Inventory Service

    Goods fetched Shipment Service Goods shipped The choreography principle @martinschimak
  29. Payment Service Inventory Service Shipment Service The orchestration principle Order

    Service Fetch goods Retrieve payment Ship goods
  30. This is how the story is often presented … Choreo-

    graphy Orches- tration Process logic Process control explicit central implicit decentral Service coupling high low @martinschimak
  31. Order Service Order placed Payment Service Payment retrieved Inventory Service

    Goods fetched Shipment Service Goods shipped Choreographies and their implicit process logic ... @martinschimak
  32. Order Service Payment Service Inventory Service Shipment Service Order placed

    Goods shipped ... can lead to a hidden form of accidental coupling Payment Service Inventory Service Goods fetched Payment retrieved ... to change implicit process logic ... Change listener 1 ... Change listener 2 ... Change listener 3 ... @martinschimak
  33. Payment Service Inventory Service Shipment Service Orchestration and its explicit

    process logic ... Order Service Fetch goods Retrieve payment Ship goods ... does not display THIS form of hidden accidental coupling...
  34. Who made the decision to use events only? @martinschimak

  35. This is how the story develops … Choreo- graphy Orches-

    tration Process logic Process control explicit central implicit decentral Service coupling high low Not necessarily Not necessarily @martinschimak
  36. Let‘s dig a bit deeper and look into this ...

    Choreo- graphy Orches- tration Process logic Process control explicit central implicit decentral Service coupling high low Not necessarily Not necessarily @martinschimak
  37. Comparing unhealthy apples and healthy oranges š Maybe Synchronous š

    Request and Response Style š Sender/Receiver Exchange š Probably Transient š Asynchronous by Nature š Fire and Forget Style š Publish/Subscribe Exchange š Probably Persistent Command Event @martinschimak
  38. Payment Service Inventory Service Shipment Service Why not asynchronous commands?

    „Doable“ ... Order Service Fetch goods Retrieve payment Ship goods Request Async Response Request Async Response Async Response Request
  39. How unhealthy is this apple ... š Maybe Synchronous š

    Request and Response Style š Sender/Receiver Exchange š Probably Transient š Asynchronous by Nature š Fire and Forget Style š Publish/Subscribe Exchange š Probably Persistent Command Event Or Asynchronous! @martinschimak
  40. ? ? ? Payment Service Inventory Service Shipment Service Why

    not fire the command? And listen to an event? Order Service Fetch goods Retrieve payment Ship goods Payment retrieved Goods fetched Goods shipped Order fulfilled Fire Fire Fire Listen Listen Listen
  41. How unhealthy is this apple ... š Maybe Synchronous š

    Request and Response Style š Sender/Receiver Exchange š Probably Transient š Asynchronous by Nature š Fire and Forget Style š Publish/Subscribe Exchange š Probably Persistent Command Event Or Asynchronous! Like Fire and Listen? @martinschimak
  42. ? Payment Service Why not publish the command? Order Service

    Retrieve payment Payment retrieved Publish @martinschimak
  43. ? Payment Service ... we get location transparency inside a

    context ... Order Service Retrieve payment Payment retrieved Publish Subscribe Financial Services Bounded Context @martinschimak
  44. ? Payment Service ... and the ability to subscribe to

    „everything“. Order Service Retrieve payment Payment retrieved Publish Subscribe Financial Services Bounded Context Subscribe Subscribe Business Monitoring Bounded Context „Order Context wanted payment to happen!“ „Financial Context retrieved payment!“
  45. The apple doesn’t look so unhealthy anymore ... š Maybe

    Synchronous š Request and Response Style š Sender/Receiver Exchange š Probably Transient š Asynchronous by Nature š Fire and Forget Style š Publish/Subscribe Exchange š Potentially Persistent Command Event Or Asynchronous! Like Fire and Listen? Like Publish and Promise to Subscribe? @martinschimak
  46. What about focusing on semantical differences only … š We

    specified an intent š This just models our “state of mind” š We use imperative tense to express intent š Defined by supplier bounded context, created by customer system š We created an outcome š This models everybody’s “state of world” š We use past tense to express an outcome š Defined and created by emitter bounded context and system Command Event @martinschimak
  47. ? Payment Service Related semantics are both defined in supplier

    context Retrieve payment Payment retrieved Financial Services Bounded Context „When YOU send this WE promise to receive and act!“ „When WE send this YOU decide to receive and act!“ Command Event @martinschimak Make the contract explicit!
  48. and Apples Oranges @martinschimak

  49. @martinschimak „Atomic“ Execution Command Intent Something should happen Domain Event

    Outcome Something happened
  50. @martinschimak „Composite“ Execution Domain Command Intent Something should happen Domain

    Event Outcome Something happened
  51. ? Payment Service Mix and match decentral orchestration and choreography

    Retrieve payment Payment retrieved Financial Context Command Event Order Service Fulfillment Context Payment retrieval failed Event Marketing Context Customer promoted Promotions service Event @martinschimak
  52. New pair of shoes ordered It‘s a supplier‘s responsibility to

    act on customer intent New pair of shoes ordered Retrieve payment Payment retrieved Domain Events Customer Supplier Payment Service @martinschimak Domain Command Domain Event
  53. New pair of shoes ordered It‘s a customer‘s responsibility to

    specify intent New pair of shoes ordered Retrieve payment Domain Events Customer Supplier Order placed Order Service @martinschimak Domain Command Domain Event
  54. New pair of shoes ordered Some responsibilities span both phases,

    but not all New pair of shoes ordered Promote customer Domain Events Payment retrieved Promotions service Customer promoted Promotions service @martinschimak Domain Command Domain Event
  55. Wait. It really depends ... on organizational responsibilities? @martinschimak

  56. Orchestration and choreography... „it really depends“. Choreo- graphy Orches- tration

    Process logic Process control explicit central implicit decentral Service coupling high low Not necessarily Not necessarily Not necessarily Not necessarily @martinschimak
  57. Embed and contain state managing business logic! Retrieve payment Payment

    retrieved Payment service “Long-running” service Seconds to weeks Payment retrieval failed @martinschimak Domain Command Domain Event
  58. “Process” is NOT horizontal! It is VERTICAL, too @martinschimak

  59. A blossoming ecosystem of saga & process managers CADENCE Baker

  60. Why not ... persisting commands? š Maybe Synchronous š Request

    and Response Style š Sender/Receiver Exchange š Probably Transient š Asynchronous by Nature š Fire and Forget Style š Publish/Subscribe Exchange š Probably Persistent Command Event Or Asynchronous! Like Fire and Listen? Like Publish and Promise to Subscribe? @martinschimak
  61. Don‘t underestimate state managing business logic... Payment retrieved Payment service

    Seconds to weeks Payment retrieval canceled Timeout Retry Version Compensate Parallelise Retrieve payment @martinschimak Domain Command Domain Event
  62. Looking behind a „long-running“ service Retrieve payment Payment retrieved Payment

    requested Charge credit card Depending on account balance Withdraw amount from account Amount Withdrawn Credit card charged Credit card failed Update credit card details Account details Credit card details updated Whenever card details are updated After two weeks Depending on the amount Amount credited Mark payment retrieved Mark payment canceled Payment failed Credit amount to account Whenever payment is canceled Mark payment received Payment retrieved
  63. Credit amount back to account Withdraw amount from cust. account

    Charge amount by credit card I want that kind of reactive business process execution Charge amount by credit card Credit amount back to account Update credit card details Check customer account balance Payment requested Depending on account balance Charge credit card Withdraw amount from account Credit card charged Whenever credit card is charged Mark payment received Payment received Amount Withdrawn Depending on the amount Mark payment received Payment received Mark paym. partly covered Payment partly covered Whenever payment p. covered Charge credit card Credit card failed Whenever credit card failed Update credit card details Credit card details updated Whenever card details are updated Charge credit card After two weeks Mark payment canceled Payment canceled Whenever payment is canceled Credit amount to account Amount credited Every two days Remind customer Customer reminded Withdraw amount from cust. account
  64. I want autonomous services - respecting boundaries Order service Payment

    service Retrieve payment Payment retrieved Payment failed Retrieve payment
  65. I want „composition transparent“ commanding Order service Retrieve payment Atomic

    or composite execution
  66. I want flexible and local technology decisions Order service Payment

    service Retrieve payment Payment retrieved Payment failed Retrieve payment Your local implementation reacting to events and commands
  67. medium.com/plexiti @martinschimak Thank you!