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

CraftConf Budapest 2018: Break your event chains! Complex event flows in distributed systems

CraftConf Budapest 2018: Break your event chains! Complex event flows in distributed systems

@berndruecker @martinschimak => May 10th, 2018 => Budapest => CraftConf

Martin Schimak

May 10, 2018
Tweet

More Decks by Martin Schimak

Other Decks in Programming

Transcript

  1. Break your event chains!
    Complex event flows in
    distributed systems.
    @berndruecker @martinschimak

    View full-size slide

  2. Berlin, Germany
    [email protected]
    @berndruecker
    Bernd Ruecker
    Co-founder and
    Developer Advocate of
    Camunda

    View full-size slide

  3. Vienna, Austria
    [email protected]
    @martinschimak
    Martin Schimak
    Into and onto de|coding
    domain language
    with Plexiti

    View full-size slide

  4. Distributed systems

    View full-size slide

  5. Let‘s have a look
    what we can
    learn from DDD

    View full-size slide

  6. Example process / Event Storming!
    Goods
    shipped
    Order
    placed
    Goods
    fetched
    Payment
    received
    Events are a concept easy to grasp for everybody in the room.

    View full-size slide

  7. Events are …
    Payment
    received
    Payment
    Strong consistency
    It already happened.
    Events let us look into the past.

    View full-size slide

  8. Events help to decouple services.
    Order
    summary
    Payment
    received
    Payment UI
    raises
    projected
    onto
    Payment Service
    Order Service

    View full-size slide

  9. Events help with cross-cutting concerns.
    Payment
    received
    Inform
    customer
    listened to by
    Payment Service
    Notification Service

    View full-size slide

  10. What about purely event-driven architectures?
    Order
    placed
    Payment Service
    Payment
    received
    Inventory Service
    Goods
    fetched
    Shipment Service
    Goods
    shipped
    When relying only on events, „intent“ is always formed inside the event consumer.

    View full-size slide

  11. Autonomous services can make their own decisions.
    To change the order of two services, we touch 4 sticky notes… but wait, even three services!
    Shipment Service
    Goods
    shipped
    Order
    placed
    Inventory Service
    Goods
    fetched
    Payment Service
    Payment
    received

    View full-size slide

  12. Our policies decide to act on facts – with commands
    Domain
    Event
    Policy
    Command
    listened to by triggers

    View full-size slide

  13. Who owns the policy in a pure event choreography?
    Payment
    received
    Start
    Fetching
    Policy
    Fetch
    goods
    listened to by triggers
    Payment Service
    Inventory Service

    View full-size slide

  14. Neither of both truly „owns“ that policy?
    Payment
    received
    Fetch
    goods
    listened to by triggers
    Payment Service
    Inventory Service
    Start
    Fetching
    Policy

    View full-size slide

  15. Extracting the policy into a mediator service
    Payment
    received
    Fetch
    goods
    listened to by triggers
    Payment Service
    Inventory Service
    Order Service
    Start
    Fetching
    Policy

    View full-size slide

  16. The order as the company‘s core business
    Place
    order
    Order
    placed
    Request
    payment
    Order Service
    Payment
    received
    Fetch
    goods
    Goods
    fetched
    Ship
    goods
    Goods
    shipped
    “When the
    order is
    placed…”
    “When the
    payment is
    received…”
    “When the
    goods are
    fetched…”
    “Then we
    are done!”
    Mark
    order as
    fulfilled
    Order
    fulfilled
    Payment Service Inventory Service Shipment Service

    View full-size slide

  17. Double check: what happens when we charge later?
    Place
    order
    Order
    placed
    Request
    payment
    Order Service
    Payment
    received
    Fetch
    goods
    Goods
    fetched
    Ship
    goods
    Goods
    shipped
    “When the
    order is
    placed…”
    “When the
    payment is
    received…”
    “When the
    goods are
    fetched…”
    “Then we
    are done!”
    Mark
    order as
    fulfilled
    Order
    fulfilled
    Payment Service
    Inventory Service Shipment Service
    “When the
    order is
    placed…”
    “When the
    payment is
    received…”
    “When the
    goods are
    fetched…”

    View full-size slide

  18. Multiple services need to collaborate
    Payment
    Shipping
    Order
    Inventory

    View full-size slide

  19. Multiple services need to collaborate
    Payment
    Shipping
    Order
    Inventory
    https://www.infoworld.com/article/3254777/application-development/
    3-common-pitfalls-of-microservices-integrationand-how-to-avoid-them.html

    View full-size slide

  20. Photo by Tookapic, available under Creative Commons CC0 1.0 license.

    View full-size slide

  21. „There was an error
    while sending your
    boarding pass“

    View full-size slide

  22. Check-in
    Web-UI
    Me
    Current situation

    View full-size slide

  23. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    Current situation

    View full-size slide

  24. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    Current situation – the bad part

    View full-size slide

  25. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    Current situation – the bad part

    View full-size slide

  26. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    Current situation – the bad part
    Stateful
    Retry

    View full-size slide

  27. We are having some technical difficulties
    and cannot present you your boarding
    pass right away.
    But we do actively retry ourselves, so
    lean back, relax and we will send it
    on time.
    …I just made this up…

    View full-size slide

  28. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    Possible situation – much better!

    View full-size slide

  29. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    Possible situation – much better!
    Stateful
    Retry

    View full-size slide

  30. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    Stateful
    Retry
    Possible situation – much better!
    The failure
    never leaves
    this scope!

    View full-size slide

  31. Persist thing
    (Entity, Document, Actor, …)
    State machine or
    workflow engine
    Typical
    concerns
    DIY = effort,
    accidental
    complexity
    Complex, proprietary,
    heavyweight, slow,
    don‘t scale,
    developer adverse
    Scheduling, Versioning,
    operating, visibility,
    scalability, …
    Handling
    State

    View full-size slide

  32. Workflow engines,
    state machines
    It is
    relevant
    in modern
    architectures

    View full-size slide

  33. CADENCE
    Silicon valley
    has recognized
    Workflow engines,
    state machines

    View full-size slide

  34. CADENCE
    There are
    lightweight open source
    options
    Workflow engines,
    state machines

    View full-size slide

  35. CADENCE
    also at scale
    Workflow engines,
    state machines

    View full-size slide

  36. CADENCE
    for todays demo
    Workflow engines,
    state machines

    View full-size slide

  37. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    A state machine!

    View full-size slide

  38. Check-in
    Barcode
    Generator
    Web-UI
    Me
    Output
    Mgmt
    A state machine!

    View full-size slide

  39. Example
    Credit
    Card
    Payment
    REST
    also available in C#

    View full-size slide

  40. Live hacking
    https://github.com/flowing/flowing-retail/

    View full-size slide

  41. Payment
    Now you have a state machine!
    Credit
    Card
    REST

    View full-size slide

  42. Distributed systems introduce complexity you have to tackle!
    Credit
    Card
    Payment
    REST

    View full-size slide

  43. Distributed
    systems

    View full-size slide

  44. It is impossible to
    differentiate certain
    failure scenarios.
    Independant of
    communication style!
    Service
    Provider
    Client

    View full-size slide

  45. Distributed systems introduce complexity you have to tackle!
    Credit
    Card
    Payment
    REST

    View full-size slide

  46. Distributed systems introduce complexity you have to tackle!
    Credit
    Card
    Payment
    REST
    Do it reliably

    View full-size slide

  47. Distributed
    systems 2007

    View full-size slide

  48. Distributed transactions using compensation *
    Compensation
    *aka Saga
    pattern

    View full-size slide

  49. Live hacking
    https://github.com/flowing/flowing-retail/

    View full-size slide

  50. Long running services
    Credit
    Card
    Payment
    Order

    View full-size slide

  51. God services?
    Credit
    Card
    Payment
    A few
    smart god services
    tell
    anemic CRUD services
    what to do
    Sam Newmann
    Order

    View full-size slide

  52. God services?
    Credit
    Card
    Payment
    Order
    A few
    smart god services
    tell
    anemic CRUD services
    what to do
    Sam Newmann

    View full-size slide

  53. „By delegating our problems to our clients we force
    them into mitigation. They become god services.“
    Credit card
    failed
    Retry with
    new credit
    card details
    Charge
    credit card
    listened to by
    triggers
    Payment Service
    Order Service

    View full-size slide

  54. Just the first requirements for a payment service
    Request
    payment
    Payment
    received
    Payment
    requested
    Charge
    credit card
    Depending
    on account
    balance
    Withdraw
    amount from
    account Amount
    Withdrawn
    Credit card
    charged
    Credit card
    failed
    Update
    credit card
    details
    Account
    details
    Credit card
    details
    updated
    Whenever
    card details
    are updated
    After two
    weeks
    Depending
    on the
    amount
    Amount
    credited
    Mark
    payment
    received
    Mark
    payment
    canceled
    Payment
    canceled
    Credit
    amount to
    account
    Whenever
    payment is
    canceled
    Mark
    payment
    received
    Payment
    received

    View full-size slide

  55. Payment as a „long-running“ service
    Request
    payment
    Payment
    received
    Payment
    canceled
    1) creates value – serving a result its client is really interested in
    2) assumes responsibility – instead of delegating troubles with internal steps to its client
    3) may go asynchronous – if needed for composite execution
    Payment Service

    View full-size slide

  56. @Saga
    class Payment {
    private var paymentAmount = 0F
    @StartSaga
    @SagaEventHandler(associationProperty = "paymentId")
    fun on(event: PaymentRequested) {
    }
    }
    e.g. Axon Messaging & Saga Management
    is cool,
    but Java works as well! :-)
    1) Correlate
    domain
    event
    2) Save
    process
    state
    3) Evaluate
    business
    policy
    4) Create
    and issue
    command

    View full-size slide

  57. Credit amount
    back to account
    Withdraw
    amount from cust.
    account
    Charge amount
    by credit card
    e.g. with Camunda as message-driven workflow
    Charge amount
    by credit card
    Credit amount
    back to account
    Update credit card
    details
    Check customer
    account balance
    Payment
    requested
    Depending
    on account
    balance
    Charge
    credit card
    Withdraw
    amount from
    account
    Credit card
    charged
    Whenever
    credit card
    is charged
    Mark
    payment
    received
    Payment
    received
    Amount
    Withdrawn
    Depending
    on the
    amount
    Mark
    payment
    received
    Payment
    received
    Mark paym.
    partly
    covered
    Payment
    partly
    covered
    Whenever
    payment
    p. covered
    Charge
    credit card
    Credit card
    failed
    Whenever
    credit card
    failed
    Update
    credit card
    details
    Credit card
    details
    updated
    Whenever
    card details
    are updated
    Charge
    credit card
    After two
    weeks
    Mark
    payment
    canceled
    Payment
    canceled
    Whenever
    payment is
    canceled
    Credit
    amount to
    account
    Amount
    credited
    Every two
    days
    Remind
    customer
    Customer
    reminded
    Withdraw
    amount from cust.
    account

    View full-size slide

  58. DDD? Long-running services respect bounded contexts!
    Order service
    Payment service
    Request
    payment
    Payment
    received
    Request
    payment
    Payment
    canceled

    View full-size slide

  59. Integration of Axon Messaging with Camunda.
    Order service
    Payment service
    Request
    payment
    Payment
    received
    Payment
    canceled
    Request
    payment
    plexiti
    de|coding domain language
    @martinschimak
    https://github.com/plexiti/axon-camunda-poc

    View full-size slide

  60. Flowing retail example: https://github.com/flowing/flowing-retail/
    Using
    Java + Spring Boot or C#
    REST or Kafka
    Camunda or Zeebe

    View full-size slide

  61. [email protected]
    @berndruecker
    http://bernd-ruecker.com/
    [email protected]
    @martinschimak
    http://plexiti.com/
    https://github.com/plexiti/axon-camunda-poc/
    http://github.com/flowing/flowing-retail/
    https://www.infoq.com/articles/events-
    workflow-automation
    Contact:
    Contact:
    Examples:
    https://www.infoworld.com/article/3254777/
    application-development/
    3-common-pitfalls-of-microservices-
    integrationand-how-to-avoid-them.html
    With thoughts from http://flowing.io
    @berndruecker | @martinschimak

    View full-size slide