Stop bashing orchestration! And long live choreography!

Stop bashing orchestration! And long live choreography!

@martinschimak -> Nov 5th, 2018 -> µCon London

2999fab21d182294fad0b2cc590fd54d?s=128

Martin Schimak

November 05, 2018
Tweet

Transcript

  1. Stop bashing orchestration … and long live choreography! Nov 5th,

    2018 -> London -> µCon @martinschimak
  2. Use synchronous request/response Forget about idempotency Design entity CRUD services

    HOWTO … do microservices and sleep simply well :-) Is ”WTF is CRUD?” Is ”Hey … it’s simple!” Is ”My framework does it!” @martinschimak
  3. But hey … there is a secret and hidden path

    to accidental coupling and god services, too … :-) @martinschimak
  4. Is A secret path to accidental coupling and god services

    Insist on using events only in between services. It always reduces coupling! Define your business processes as a horizontal, cross-cutting concern! Design service APIs as collections of atomically executable operations! Is Is ”We need consistency!” ”Sure. Events first!” ”What else?” @martinschimak
  5. Some services. Not micro. But not because of their size.

    @martinschimak ESB - Enterprise Service Bus Order Service Payment Service Inventory Service Shipment Service
  6. Some services. Decoupled. And a really dumb pipe! @martinschimak “Dumb”

    Messaging: no business logic in here Order Service Payment Service Inventory Service Shipment Service
  7. Item ordered My context of sophisticated fulfillments Power traded Order

    fulfillment Power trade execution Coverage extension requested Insurance Policy Underwriting @martinschimak
  8. plexiti.com @martinschimak

  9. Eric Evans, 2004

  10. 2004 2006 2008 2018 2010 2012 2014 2016 ? @martinschimak

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

    Denver Berlin ? Vienna @martinschimak
  12. Decoupled? We pretty well understand the reads … @martinschimak Order

    Service Payment Service Inventory Service Shipment Service Order summary Payment retrieved Goods fetched Goods shipped
  13. Events decouple services! @martinschimak Temporally decoupled services Decoupled non-functional requirements

    Semantical coupling only
  14. Decoupled? How to trigger the writes… via events ,too? @martinschimak

    Order Service Payment Service Inventory Service Shipment Service Order placed Payment retrieved Goods fetched Goods shipped Choreography
  15. Payment Service Inventory Service Shipment Service Or directly trigger the

    writes … via requests? Order Service Fetch goods Retrieve payment Ship goods Orchestration
  16. 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
  17. Choreography, it is! @martinschimak

  18. Choreographies and their implicit process logic ... @martinschimak Order Service

    Payment Service Inventory Service Shipment Service Order placed Payment retrieved Goods fetched Goods shipped To change the process …
  19. Payment retrieved Goods fetched ... leads to a hidden form

    of accidental coupling @martinschimak Order Service Shipment Service Order placed Goods shipped Payment Service Inventory Service Change service 1 ... Change service 2 ... Change service 3 ... Goods fetched Payment retrieved … we must change three services… ouch!
  20. 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 ...!
  21. A secret path to accidental coupling and god services Insist

    on using events only in between services. It always reduces coupling! Define your business processes as a horizontal, cross-cutting concern! Design service APIs as collections of atomically executable operations! Is ”We need consistency!” ”Sure. Events first!” ”What else?” @martinschimak
  22. More process logic? Even more coupled by choreography. Choreo- graphy

    Orches- tration Process logic Process control explicit central implicit decentral Service coupling high low Not necessarily Not necessarily @martinschimak
  23. Does this guy want us to buy into this? Choreo-

    graphy Orches- tration Process logic Process control explicit central implicit decentral Service coupling high low Not necessarily Not necessarily @martinschimak
  24. I want events to properly decouple the reads … @martinschimak

    Order Service Payment Service Inventory Service Shipment Service Order summary Payment retrieved Goods fetched Goods shipped
  25. Events … and intent. @martinschimak „Events have no intent.“ -

    Jonas Bonér Payment retrieved Outcome
  26. Triggering writes … via events? @martinschimak Order Service Payment Service

    Order placed … whenever I see the order placed I retrieve the payment… Defines name & meaning … Couples name & meaning …
  27. Events … and intent. „Commands are all about intent. @martinschimak

    Events have no intent.“ - Jonas Bonér Intent Retrieve payment Payment retrieved Outcome commands
  28. Triggering writes … via events? @martinschimak Order Service Payment Service

    Order placed Defines name & meaning … Couples name & meaning …
  29. Triggering writes … via commands? @martinschimak Order Service Payment Service

    … I retrieve the payment when I see my command Couples name & meaning … Defines name & meaning … Retrieve payment
  30. Payment Service Inventory Service Shipment Service The orchestration principle using

    commands … Order Service Fetch goods Retrieve payment Ship goods
  31. ? ? ? 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
  32. Events couple receiver. Fired commands couple sender. @martinschimak Order Service

    Payment Service Couples name & meaning … Defines name & meaning … Retrieve payment Payment retrieved
  33. Binding events or commands depends on responsibilities @martinschimak Order Service

    Payment Service Retrieve payment Payment retrieved Promotions Service Fire essentials as commands and listen to events Customer promoted Act on defined command React to others’ event
  34. Retrieve payment Payment retrieved @martinschimak

  35. A stony path to service autonomy: think & balance. Insist

    on using events only in between services. It always reduces coupling! Define your business processes as a horizontal, cross-cutting concern! Design service APIs as collections of atomically executable operations! ”We need consistency!” ”What else?” Carefully bind by either EVENTor COMMAND to minimise coupling! ”Sure. Events first!” @martinschimak
  36. We all know similar process organization diagrams… Order Payment Inventory

    Shipment Order Subscription Business Capabilities? Business Processes? Payment Inventory Shipment One-time Order @martinschimak
  37. When we look into payments, we discover a process …

    Payment Credit card Handling Accounting Bank Account Handling One-time Order Order Subscription @martinschimak
  38. I design services as capabilities implemented by processes @martinschimak Order

    Service Payment Service Retrieve payment Payment retrieved Process Process Order Fulfillment Service Payment Retrieval Service Capability Capability
  39. Both patterns harden global, horizontal thinking … Orchestration hardens a

    global process thinking … … but choreography hardens the horizontal thinking too … @martinschimak
  40. Services represent processes as little state machines @martinschimak Order Fulfillment

    Service Payment Retrieval Service Credit Card Charging Service State transitions State transitions State transitions
  41. “Process” is NOT horizontal! It is VERTICAL, too @martinschimak

  42. A stony path to service autonomy: think & balance. Carefully

    bind by either EVENTor COMMAND to minimise coupling! Define your business processes as a horizontal, cross-cutting concern! Design service APIs as collections of atomically executable operations! ”We need consistency!” ”What else?” Understand that business processes are a VERTICAL and LOCAL service concern! ”Sure. Events first!” State transitions @martinschimak
  43. Services deliver capabilities via „long-running“ APIs @martinschimak Order Fulfillment Service

    Payment Retrieval Service Credit Card Charging Service State transitions State transitions State transitions Retrieve payment Payment retrieved Charge credit card Credit card charged Fulfill order Order fulfilled Seconds to weeks Seconds Days to months Payment failed Order not fulfilled Credit card expired
  44. Services deliver capabilities via „long-running“ APIs @martinschimak Payment Retrieval Service

    Order Fulfillment Service Charge credit card Retrieve payment Payment requested Payment retrieved
  45. Services deliver capabilities via „responsible“ APIs @martinschimak Payment Retrieval Service

    Order Fulfillment Service Charge credit card Retrieve payment Payment requested Payment failed Retry with new credit card details
  46. Services deliver capabilities via „responsible“ APIs @martinschimak Payment Retrieval Service

    Order Fulfillment Service Retrieve payment Payment requested Credit card expired Charge credit card Payment retrieved Retry with new credit card details
  47. „God“ like services? Stop bashing „orchestration“, start bashing bad API

    design! :-) @martinschimak Exposing your CRUD operations Exposing your very own problems Exposing atomic or too fine-grained operations
  48. Atomic vs. composite command execution Request payment Payment requested Typically

    we see a „command“ as the intent to change a write model... … but the customer‘s or service clients intent is often targeted at a more valuable business result, which needs many intermediate steps to be achieved. Retrieve payment Atomic, trans- actional view Composite, long- running view Payment requested Payment retrieved @martinschimak
  49. A stony path to service autonomy: think & balance. Carefully

    bind by either EVENTor COMMAND to minimise coupling! Understand that business processes are a VERTICAL and LOCAL service concern! Design service APIs as collections of atomically executable operations! ”We need consistency!” ”What else?” ”Sure. Events first!” Services are small state machines State transitions Design service APIs around RESPONSIBLE and LONG-RUNNING capabilities! @martinschimak
  50. Mix and match … locally. @martinschimak Order Fulfillment Service Payment

    Retrieval Service Retrieve payment Payment retrieved Customer Promotion Service Take care of a coarse grained order fulfillment Customer promoted Act on command and take care of payment React to event and take care of promotion
  51. Orchestration and Choreography instead of this false dichotomy @martinschimak request

    and response … A local piece of ACTIVELY triggering work A local piece of REACTIVELY triggered work … event collaboration
  52. Instead of discussing global patterns … 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 Not necessarily Not necessarily
  53. … let‘s think more how to keep the local balance!

    Event Command Process logic Process control Intent Customer & Supplier Outcome Outcome & Reaction Service coupling By Sender By Receiver @martinschimak I need both! I need both! I need both!
  54. medium.com/plexiti @martinschimak Thank you!