This document discusses orchestrating microservices using event-driven communication and process managers. It describes how microservices communicate asynchronously using events without direct knowledge of each other. Process managers listen for events, transform them into commands, and handle long-running workflows and state. This approach provides visibility into end-to-end processes while maintaining autonomy and decoupling between microservices. The document also cautions against over-engineering with complex BPM suites and recommends using lightweight, embeddable process engines.
7. Disclaimer: I do not advertise microservices!
But assume you [want | have] to use microservices
â what to do then?
8. Microservices
âą Independent components
âą Independent deployments
âą Decoupling between components
âą Dedicated teams to fight conways law
âą Autonomy of technology decisions
âą Avoid horizontal team boundaries
âą New DevOps paradigms
Microservice
Microservice
Microservice
Monolith
A
B
C
A
B
C
31. Saga
The classical Saga pattern example
book
hotel
book
car
book
flight
cancel
hotel
cancel
car
1. 2. 3.
5.6.
4. In case of
failure trigger
compensations
book
trip
35. Process Manager
âą Do event command transformation
âą Handle state for long running flows
36. Reactive actor with Akka
https://github.com/VaughnVernon/ReactiveMessagingPatterns_ActorModel/blob/master/src
/co/vaughnvernon/reactiveenterprise/processmanager/ProcessManager.scala#L91
42. Process Manager
âą Do event command transformation
âą Handle state for long running flows
âą Implement the flow as 1st class citizen
of domain logic
43. Martin Fowler
Event notification is nice because it implies a low level of
coupling, and is pretty simple to set up. It can become
problematic, however, if there really is a logical flow
that runs over various event notifications. The
problem is that it can be hard to see such a flow as it's
not explicit in any program text. Often the only way to
figure out this flow is from monitoring a live system.
This can make it hard to debug and modify such a flow.
The danger is that it's very easy to make nicely
decoupled systems with event notification, without
realizing that you're losing sight of that larger-scale
flow, and thus set yourself up for trouble in future years
https://martinfowler.com/articles/201701-event-driven.html
44. It is about visbility
Payment
Retrieve
payment
Order
placed Order
45. It is about ubiquitous language!
Ubiquitous Language
Software
Experts
Domain
Experts
73. Lightweight and embeddable engine
Engine must be
âą easy to use
âą developer friendly
also in the scope of multiple
scopes/aggregates/services
âą technically
âą license model
Payment
Order
engine
engine
âŠ
Inventory
Shipping
âŠ
engine
74. Slides are nice â
but what about code?
Sure:
http://github.com/flowing/