Slides from a talk held at WJAX Munic on 9th of November (and some other meetups later in November) about how to tackle collaboration of microservices. Most of the talk was live coding, the respective code is here: https://github.com/flowing/flowing-retail.

1. Collaboration of (micro-)services
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. We start with a simple example
Credit
Card
Payment
REST

9. Live hacking
Getting from https://github.com/flowing/flowing-retail/blob/master/payment-
rest/src/main/java/io/flowing/retail/payment/port/resthacks/PaymentRestHacksControllerV1.java to V2

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

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

12. Gracefully degrade
instead of
epic fails!

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

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

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

17. State machines
or workflow
engines
CADENCE
Baker

18. Live hacking
Getting to https://github.com/flowing/flowing-retail/blob/master/payment-
rest/src/main/java/io/flowing/retail/payment/port/resthacks/PaymentRestHacksControllerV3.java

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

20. Live hacking
Getting to https://github.com/flowing/flowing-retail/blob/master/payment-
rest/src/main/java/io/flowing/retail/payment/port/resthacks/PaymentRestHacksControllerV4.java

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

22. Fallbacks make
your system
more resilient

23. Workflows live inside service boundaries

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

25. But: Beware of DOS attacks by retries!

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

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

28. Operating messaging systems is hard.

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

30. Live hacking
Getting to https://github.com/flowing/flowing-retail/blob/master/payment-
rest/src/main/java/io/flowing/retail/payment/port/resthacks/PaymentRestHacksControllerV5.java

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

32. Live hacking
Getting to https://github.com/flowing/flowing-retail/blob/master/payment-
rest/src/main/java/io/flowing/retail/payment/port/resthacks/PaymentRestHacksControllerV6.java

33. 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…

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

35. The world beyond request/response

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

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

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

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

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

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

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

43. Workflows live inside service boundaries

44. Explicit flows help separate domain and infrastructure
Infrastructure
Aggregates,
Domain Events,
Domain Services,
etc …
+ the flow
Workflow
Engine
Payment
Application
Domain

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

46. Live hacking

47. 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)

49. New kid on the block
https://zeebe.io/
Zeebe
Broker
Your
application
Binary (MsgPack)
Support streaming & batching
Client
Horiziontally
scalable
Append only log / event sourcing
Peer-to-peer
cluster

50. Thank you!

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

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