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
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
Some services. Not micro. But not because of their size. @martinschimak ESB - Enterprise Service Bus Order Service Payment Service Inventory Service Shipment Service
Some services. Decoupled. And a really dumb pipe! @martinschimak “Dumb” Messaging: no business logic in here Order Service Payment Service Inventory Service Shipment Service
Item ordered My context of sophisticated fulfillments Power traded Order fulfillment Power trade execution Coverage extension requested Insurance Policy Underwriting @martinschimak
Decoupled? We pretty well understand the reads … @martinschimak Order Service Payment Service Inventory Service Shipment Service Order summary Payment retrieved Goods fetched Goods shipped
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
Payment Service Inventory Service Shipment Service Or directly trigger the writes … via requests? Order Service Fetch goods Retrieve payment Ship goods Orchestration
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
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 …
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!
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 ...!
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
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
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
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
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 …
Events … and intent. „Commands are all about intent. @martinschimak Events have no intent.“ - Jonas Bonér Intent Retrieve payment Payment retrieved Outcome commands
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
? ? ? 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
Events couple receiver. Fired commands couple sender. @martinschimak Order Service Payment Service Couples name & meaning … Defines name & meaning … Retrieve payment Payment retrieved
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
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
We all know similar process organization diagrams… Order Payment Inventory Shipment Order Subscription Business Capabilities? Business Processes? Payment Inventory Shipment One-time Order @martinschimak
When we look into payments, we discover a process … Payment Credit card Handling Accounting Bank Account Handling One-time Order Order Subscription @martinschimak
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
Both patterns harden global, horizontal thinking … Orchestration hardens a global process thinking … … but choreography hardens the horizontal thinking too … @martinschimak
Services represent processes as little state machines @martinschimak Order Fulfillment Service Payment Retrieval Service Credit Card Charging Service State transitions State transitions State transitions
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
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
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
„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
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
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
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
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
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
… 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!
martinschimak
kazutan
lemolatoon
usualoma
kin29
speed1313
gennei
77web
microcms
tanakahisateru
iwaken71
dicoding
siketyan
jeffersonlam
aleyda
samanthasiow
hursman
kastner
rmw
myddelton
carmenintech
akmur
lemiorhan
zakiyama
scottboms