The document discusses the complexities and strategies involved in (micro-)service collaboration, emphasizing the transition from synchronous to asynchronous communication. It highlights the importance of designing systems for resilience, including the use of state machines and workflow engines to manage long-running services. The presentation encourages understanding distributed systems' nuances and utilizing tools like circuit breakers and event-driven designs to handle service interactions effectively.

1. (Micro-)service collaboration
WJAX, Munic, 08th of November 2017
mail@bernd-ruecker.com | @berndruecker
With thoughts from http://flowing.io
@berndruecker | @martinschimak

3. Simplified example:
dash button
Photo by 0xF2, available under Creative Commons BY-ND 2.0
license. https://www.flickr.com/photos/0xf2/29873149904/

4. Basic idea of dedicated, autonomous (micro-) services
Checkout
Payment
Inventory
Shipment
Dedicated Application Processes
Dedicated Persistence Backends
Dedicated Development Teams

5. But: A lot of them…
Checkout
Payment
Inventory
Shipment
The complexity
moves to the
collaboration of the
services

6. Distributed systems

7. My plan for today:
Sync -> async -> beyond request/response
(just a teaser – mostly live coding)

8. Live hacking

9. Circuit
Breaker
Photo by CITYEDV, available under Creative Commons CC0 1.0 license.

10. Photo by Pearson Scott Foresman, available under Public Domain license.

11. Gracefully degrade
instead of
epic fails!

13. Ask: who is responsible to deal with problems?
Order
Credit
Card
Payment

14. A good service cares about his sh.. – especially
failures.
Sometimes it is better to introduce (persistent) state
and handle it yourself.

15. Persist thing with
Entity, Actor, …
State machine or
workflow engine
DIY
Output
Mgmt
PDF
created
How to
implement long-
running services?

16. State machines
or workflow
engines
CADENCE
Baker

17. Live hacking

18. But my customer wants to have the ticket right
away!

19. Finally I get my boarding pass!
This can also take
days to complete now!

20. Fallbacks make
your system
more resilient

21. Synchronous request/response
+ Easy to do
- Availability erosion, latency creep
~ Requires circuit breaker, retry,
fallback, suspension, …

22. But: Beware of DOS attacks by retries!

23. Synchronous communication
is the crystal meth of
distributed programming
Todd Montgomery and Martin Thompson
in “How did we end up here” at GOTO Chicago 2015

24. Better asynchronous communication?
That typically means: messaging
systems.

25. Operating messaging systems is hard.

26. You could also ask for work
Get work
Complete/Fail
Work
Distribution
Service

27. Live hacking

28. Design
for
failure!
2356143672_f5f88797d5_b.jpg
Photo by GalaticWanderlust, available under Creative Commons BY 2.0 license.

29. In general, application developers simply do
not implement large scalable applications
assuming distributed transactions. When
they attempt to use distributed transactions,
the projects founder because the
performance costs and fragility make them
impractical. Natural selection kicks in…

30. Business
transactions
can work
without
two phase
commit!
Photo by Gerhard51, available under Creative Commons CC0 1.0 license.

31. The world beyond request/response

32. Request/Response: temporally coupled services
Checkout
Payment
Inventory
Shipment
„The button blinks green
if we can ship the item
within 24 hours!“
Request Response

33. Events: temporal decoupling with read models
Checkout
Payment
Inventory
Shipment
„The button blinks green
if we can ship the item
within 24 hours!“
Events are facts about
what happened (in the past)
Good
Fetched
Good
Stored
Read
Model

34. Events can decrease coupling*
*e.g. decentral data-management, read models, …

35. Events: peer-to-peer event choreographies
Checkout
Payment
Inventory
Shipment
Order
placed
Payment
received
Good
shipped
„When the button is pressed, an
order is placed - and fulfilled!“
Good
fetched

36. Events: peer-to-peer event choreographies
Please fetch
the goods
before waiting
for payment
Some
customers can
pay via invoice
…
Checkout
Payment
Inventory
Shipment
Good
fetched
Order
placed
Payment
received
Good
shipped

37. Events can increase coupling*
*e.g. complex peer-to-peer event chains

38. Extract the end-to-end responsibility
Order
Checkout
Payment
Inventory
Shipment
Order
placed
Retrieve
payment
Commands have an
intent about what needs
to happen in the future
Please fetch
the goods
before waiting
for payment
Some
customers can
pay via invoice
Payment
received
Retrieve
payment

39. Workflows live inside service boundaries

40. Example
InventoryPaymentOrder ShippingCheckout Monitor
https://github.com/flowing/flowing-retail/
Human
Tasks

41. Live hacking

42. Wrap-up
# Understand complexity of distributed systems
Sync/async, request/response, event-driven
# Know strategies and tools to handle it
e.g.Circuit breaker (Hystrix)
State machine for visual flow, wait, timeout,
retry and compensation (Camunda, Zeebe)

44. Thank you!

45. Code:
https://github.com/berndruecker
Slides:
https://bernd-ruecker.com
Blog:
https://blog.bernd-ruecker.com
Feedback:
https://bernd-ruecker.com/feedback
With thoughts from http://flowing.io
@berndruecker | @martinschimak

46. Images licensed from iStock
no attribution required
All icons licensed from Noun Project
no attribution required
Own photos