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

Stop bashing orchestration! And long live choreography!

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. Stop bashing orchestration … and long live choreography!
    Nov 5th, 2018 -> London -> µCon
    @martinschimak

    View full-size slide

  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

    View full-size slide

  3. But hey … there is a secret and hidden
    path to
    accidental coupling and god services, too … :-)
    @martinschimak

    View full-size slide

  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

    View full-size slide

  5. Some services. Not micro. But not because of their size.
    @martinschimak
    ESB - Enterprise Service Bus
    Order Service Payment Service Inventory Service Shipment Service

    View full-size slide

  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

    View full-size slide

  7. Item
    ordered
    My context of sophisticated fulfillments
    Power
    traded
    Order
    fulfillment
    Power trade
    execution
    Coverage
    extension
    requested
    Insurance Policy
    Underwriting
    @martinschimak

    View full-size slide

  8. plexiti.com
    @martinschimak

    View full-size slide

  9. Eric Evans, 2004

    View full-size slide

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

    View full-size slide

  11. 2004 2006 2008 2018
    2010 2012 2014 2016
    London Amsterdam Denver
    Berlin
    ?
    Vienna
    @martinschimak

    View full-size slide

  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

    View full-size slide

  13. Events decouple services!
    @martinschimak
    Temporally
    decoupled
    services
    Decoupled
    non-functional
    requirements
    Semantical
    coupling only

    View full-size slide

  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

    View full-size slide

  15. Payment Service Inventory Service Shipment Service
    Or directly trigger the writes … via requests?
    Order Service
    Fetch
    goods
    Retrieve
    payment
    Ship
    goods
    Orchestration

    View full-size slide

  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

    View full-size slide

  17. Choreography, it is!
    @martinschimak

    View full-size slide

  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 …

    View full-size slide

  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!

    View full-size slide

  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 ...!

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  25. Events … and intent.
    @martinschimak
    „Events have no intent.“
    - Jonas Bonér
    Payment
    retrieved
    Outcome

    View full-size slide

  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 …

    View full-size slide

  27. Events … and intent.
    „Commands are all about
    intent.
    @martinschimak
    Events have no intent.“
    - Jonas Bonér
    Intent
    Retrieve
    payment
    Payment
    retrieved
    Outcome
    commands

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  30. Payment Service Inventory Service Shipment Service
    The orchestration principle using commands …
    Order Service
    Fetch
    goods
    Retrieve
    payment
    Ship
    goods

    View full-size slide

  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

    View full-size slide

  32. Events couple receiver. Fired commands couple sender.
    @martinschimak
    Order Service Payment Service
    Couples name
    & meaning …
    Defines name
    & meaning …
    Retrieve
    payment
    Payment
    retrieved

    View full-size slide

  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

    View full-size slide

  34. Retrieve
    payment
    Payment
    retrieved
    @martinschimak

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  37. When we look into payments, we discover a process …
    Payment
    Credit card
    Handling
    Accounting
    Bank Account
    Handling
    One-time Order Order
    Subscription
    @martinschimak

    View full-size slide

  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

    View full-size slide

  39. Both patterns harden global, horizontal thinking …
    Orchestration hardens a
    global process thinking …
    … but choreography hardens
    the horizontal thinking too …
    @martinschimak

    View full-size slide

  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

    View full-size slide

  41. “Process” is NOT horizontal!
    It is VERTICAL, too
    @martinschimak

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  44. Services deliver capabilities via „long-running“ APIs
    @martinschimak
    Payment
    Retrieval Service
    Order Fulfillment
    Service
    Charge
    credit card
    Retrieve
    payment
    Payment
    requested
    Payment
    retrieved

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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!

    View full-size slide

  54. medium.com/plexiti @martinschimak
    Thank you!

    View full-size slide