Stop bashing orchestration! And long live choreography!

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

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!