This document discusses orchestrating microservices and implementing event-driven architectures. It describes challenges in distributed systems like synchronous vs asynchronous collaboration. It presents the saga pattern for distributed transactions and discusses using BPMN for modeling processes across microservices. The document demonstrates a live example using Flowing and introduces the Zeebe workflow engine for distributed orchestration in microservices architectures.

1. Orchestration of microservices
mail@bernd-ruecker.com
With thoughts from http://flowing.io
@berndruecker | @martinschimak

2. Software is
eating the
world.
Marc Andreessen,
Entrepreneur &
Investor
„

3. Applications
Platforms &
collaborating
systems

4. to pivot | pivoted, pivoted | [Tech]

5. If you are not
embarrassed
by the first
version of your
product, you’ve
launched too
late.
Reid Hoffman,
Co-Founder LinkedIn
(and others)
„

6. Microservices: It is about speed and agility at scale
• Small components with
clear responsibilities
• Isolation
• Autonomy
• Replaceability
• Flexibility
• Experimentation
• Resilience
• Individual
scalability
DevOps, polyglott, asynchronous, reactive, message- / event-driven

7. Example
Checkout Payment Inventory Shipping
Bus

8. Example
Checkout Payment Inventory Shipping
Bus
Order
Placed
Does not
know
recepient
Does not
know
sender
Decentral data
management
Smart endpoints
and dumb pipes
Event: Fact that
happened in the past,
Immutable fact,
0..n recepients
Order
Placed
Customer
status
changed

9. Misconceptions in the microservice community
*Picture randomly taken from http://wareflo.com/2016/11/from-apis-to-microservices-workflow-orchestration-and-choreography-across-healthcare-organizations/. Not connected to statements on slide.
Orchestration…
…introduces single point of
failure…
…leads to god services…
…leads to tight coupling…
„

10. End-to-end capabilities using event flows?
InventoryPayment ShippingCheckout
Order
placed
Payment
received
Goods
fetched
Goods
shipped

11. Shipping
Goods
shipped
End-to-end capabilities using event flows?
InventoryPaymentCheckout
Order
placed
Payment
received
Goods
fetched
Please fetch
the goods
while waiting
for payment
Some
customers can
pay via invoice
…

12. Commanding is equally important!
InventoryPaymentOrder ShippingCheckout
Bus
Order
Placed
Event: Fact,
happened in the past,
immutable,
0..n recepients
Order
Placed
Retrieve
Payment
Command: Intend,
1 recipient.
Fetch
Goods
Ship
Goods

13. End-to-end capability as 1st class citizen
InventoryPaymentOrder ShippingCheckout
Core
Capabilities
Support
Capabilities
Business
Capabilities

14. Event command transformation
Payment
Retrieve
Payment
Order
Placed Order
Command
Something has to happen
in the future
1 recipient
Event
Something has
happend
in the past
0..n recipients
Conciously
decide where to
do the coupling
Transformation
Customer
Status
Changed

15. How to implement?

16. Microservice architectures are distributed systems
InventoryPaymentOrder ShippingCheckout
Bus

17. Distributed systems

18. Service A
Challenge: Synchronous collaboration
Call
service B
Service B
The network is unreliable
Hystrix adds circuit
breaker & fail fast
Retry capability & async
behavior is missing

19. Service A
Challenge: Asynchronous collaboration
Send
message
to B
Service B
Wait for
response
Timeout handling
Message correlation &
deduplication
State handling
Parallelism & merging

20. Challenge: Distributed transactions
1. book
hotel
2. book
car
3. book
flight
6.
cancel
hotel
5.
cancel
car
4. In case of
failure trigger
compensations
book
trip
Service A
Car ServiceHotel Service Flight Service
ACID-Transactions
only local in the
service contexts
Distributed
transaction via Saga
pattern using
compensating
activities

21. Implement yourself? *
* How hard can it be?

22. Routing
slip
Persistent thing
(Entity, Actor, …)
State machine
How to
implement?

23. Routing
slip
Persistent thing
(Entity, Actor, …)
State machine

24. What BPMN can do
* Modeled in BPMN
= ISO Standard for modeling and execution

25. What BPMN can do

26. What BPMN can do

27. State machines solve some hard developer problems
Monitoring &
Operations
Handling of time &
timeouts
Retry
Visibility &
Reporting
Versioning
Compensation
Message correlation &
deduplication
Performance &
scalability

28. Living documentation

29. Executable specifications

30. Operational visibility
345 67812

31. BPM?

33. … and death by
properties panel
Same story with BPM:
Shiny vendors promised zero-code …
proprietary, alien
like tools …

34. BPM done right
Developer friendly Composable BizDevOps

37. End-to-end processes cross microservice boundaries
Order
Inventory
Payment

38. Payment
Distributed flows are owned by microservices
Order
Distributed
orchestration

39. Order
Order
Order
Order
Architecture
Order
Engine A
Payment
Engine B
Monitoring
Human Task
Management
Coarse grained
central
monitoring
Fine grained
monitoring &
operations
(per context)
DevOps
Tec
Ops Biz
Ops
Central

40. Live hacking example
InventoryPaymentOrder ShippingCheckout Monitor
https://github.com/flowing/flowing-retail/

41. Live hacking

42. Container
(e.g. Tomcat, WildFly, Websphere, …)
Architecture possibilities
Your application
Engine
DB
BPMN Java …
Your application
Engine
DB
BPMN Java …
Engine
(Docker,
Tomcat, …)
Your application
DB
Embedded engine Container managed engine Remote engine
BPMN
Java, C#,
Go, JS, …

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

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