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.

1. Orchestration of Microservices
bernd.ruecker@camunda.com
With thoughts from http://flowing.io
@berndruecker | @martinschimak

2. Orchestration? Microservices?

3. AT&T

4. Assume you want
to build a Dash
button

5. pay receive
shipment
place
order
I want to have
one item!
I am happy!

6. How to build?

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

9. Event driven microservices
Microservice Microservice Microservice
A B C

10. Communication via events
Microservice Microservice
A C
Event
event name
payload
no receipient

11. Communication via Events
Microservice Microservice
A C
Event
Does not
know
about C
Does not
know
about A

12. It is not SOA and
not about a
central ESB.
http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html

13. It is not SOA
Service Service
A C
ESB
„smart endpoints
and dumb pipes”

14. Value proposition: fight conway, keep agility and ease changes
Microservice Microservice
A C

15. Conways Law
Organisation
Software System

16. https://www.flickr.com/photos/12567713@N00/310639290

17. Yeah.

18. Business Capabilities
Bounded
Contexts
=
Microservices
Order
placed
Shop Payment Shipping
Business
Outputs /
Domain
Events
Inventory
Payment
received
Goods
fetched
Goods
shipped

19. Eventflow
Order
placed
Payment
received
Goods
fetched
Goods
shipped
InventoryPayment ShippingShop

20. Let‘s zoom in the payment context
Payment
Order
placed
Payment
received

21. Let‘s zoom in the payment context
Payment
Order
placed
Payment
received
The payment context
has to listen to
„order placed“ event

22. De-coupling?
Payment
Order
placed
Service
fullfilled
…
Whenever a new client requires
payment, the payment context
has to be touched
The payment context has to know
all possible events that trigger a
payment
Subscription
confirmed

23. Event command transformation
Payment
Retrieve
payment
Order
placed Transformation
Command
Something has to happen
in the future
1 recipient
Event
Something has happend
in the past
0..n recipients

24. Order context
Payment
Retrieve
payment
Order
placed Order

25. Event vs. command
Payment
Retrieve
payment
Order
placed Order
decide where to
do the coupling

26. Vaughn Vernon
„Process Managers
transform Events into
Commands“
At IDDD Workshop February 2017

28. Some things in live might be slow
Payment
Retrieve
payment
Order
placed Order
Payment
retrieved

29. Long running flows
require persistent state

30. In microservice architectures everything
leaving the service boundary is
potentially long running

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

32. How to
implement?

34. Process Manager

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

37. State in entity

38. Routing slip
http://vasters.com/archive/Sagas.html

39. State machine
http://camunda.org/

40. Logic remains in normal code

41. Tools provide persistent state, visibility, …
+

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

46. It is about changability

47. New business requirements
Order
placed
Payment
received
Goods
fetched
Goods
shipped
InventoryPayment ShippingShop
VIP customers can order with
invoice (and pay later)

48. New business requirements
Order
placed
Payment
received
Goods
fetched
Goods
shipped
InventoryPayment ShippingShop
VIP customers can order with
invoice (and pay later)
If VIP
customer
If not VIP
customer
Order
billed
Billing
If VIP
customer

49. Adjusted flow

50. It helps you as a developer!

51. Error and timeout handling

52. Handling complex scenarios

53. Compensation

54. The power of graphics
Graphics
Code
http://vasters.com/archive/Sagas.html

55. Smells like
„BPM“?

56. The 7 sins of workflow
3
2
4
6
5
7
1
http://blog.bernd-ruecker.com/

57. The 7 sins of workflow
Zero-code suites
Homegrown
engine
No engine Wrong engine Wrong usage
4
6
5
7
http://blog.bernd-ruecker.com/

58. Death by properties panel
Script:
Please enter your complex code here.
(Without IDE support of course!)

59. BPM Suites
By the way, we introduce an own
development approach, IDE, version
control, user management, reporting, …

60. Zero code & developers
We have a lot of
problems!
It totally sucks!
I hate BPM!

61. Bernd Rücker
Consultant & Evangelist
> 10+ years workflow
http://bernd-ruecker.com/
bernd.ruecker@camunda.com
Co-founder Camunda
http://camunda.org/

63. Define flows programatically or graphically

64. Define flows programatically or graphically
Todo…

65. Productive development and testing

66. Developer
friendly

67. Do it yourself? Actor
Entity
Routing Slip
© Picture from http://www.windtraveler.net/2010_06_01_archive.html

68. Think about subsequent requirements
Monitoring &
Operations
Visibility
Versioning
Time &
Timeouts
Domain Logic

69. The 7 sins of workflow
Zero-code suites
Homegrown
engine
Granularity
bloopers
BPM monolith Stakeholders
habitat violation
Over engineering
No engine Wrong engine Wrong usage
http://blog.bernd-ruecker.com/
4 5
7

70. The end-to-end process?

71. You are not forced to violate the bounded context!
Order Feedback
Inventory
Payment

72. Payment
Local flows in the bounded contexts
Order

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/

75. Demo architecture
InventoryPaymentOrder Shipping
H2
Shop Monitor
Camunda
Webapp
on Tomcat
for demo in single Java VM for simplicity
http://flowing.io/

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

78. Thank you!