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

Stop bashing orchestration! And long live chore...

Stop bashing orchestration! And long live choreography!

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

Martin Schimak

November 05, 2018
Tweet

More Decks by Martin Schimak

Other Decks in Programming

Transcript

  1. 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
  2. But hey … there is a secret and hidden path

    to accidental coupling and god services, too … :-) @martinschimak
  3. 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
  4. Some services. Not micro. But not because of their size.

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

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

    fulfillment Power trade execution Coverage extension requested Insurance Policy Underwriting @martinschimak
  7. 2004 2006 2008 2018 2010 2012 2014 2016 London Amsterdam

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

    Service Payment Service Inventory Service Shipment Service Order summary Payment retrieved Goods fetched Goods shipped
  9. 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
  10. Payment Service Inventory Service Shipment Service Or directly trigger the

    writes … via requests? Order Service Fetch goods Retrieve payment Ship goods Orchestration
  11. 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
  12. 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 …
  13. 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!
  14. 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 ...!
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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 …
  20. Events … and intent. „Commands are all about intent. @martinschimak

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

    Order placed Defines name & meaning … Couples name & meaning …
  22. 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
  23. Payment Service Inventory Service Shipment Service The orchestration principle using

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

    Payment Service Couples name & meaning … Defines name & meaning … Retrieve payment Payment retrieved
  26. 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
  27. 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
  28. We all know similar process organization diagrams… Order Payment Inventory

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

    Payment Credit card Handling Accounting Bank Account Handling One-time Order Order Subscription @martinschimak
  30. 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
  31. Both patterns harden global, horizontal thinking … Orchestration hardens a

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

    Service Payment Retrieval Service Credit Card Charging Service State transitions State transitions State transitions
  33. 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
  34. 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
  35. Services deliver capabilities via „long-running“ APIs @martinschimak Payment Retrieval Service

    Order Fulfillment Service Charge credit card Retrieve payment Payment requested Payment retrieved
  36. 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
  37. 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
  38. „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
  39. 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
  40. 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
  41. 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
  42. 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
  43. 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
  44. … 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!