Slides from my talk at Java Forum Stuttgart on 6th of June 2017.

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

2. AT&T

3. Microservoices?

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

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

6. Increasing
complexity
of relation-
ships

7. Event-Driven Microservices
Microservice Microservice
A B
Event
event name
payload
no receipient

8. Event-Driven Microservices
Microservice Microservice
A B
Event
Does not
know
about B
Does not
know
about A

9. Isn‘t that SOA?
Service Service
A B
ESB

10. It is not SOA
Service Service
A B
ESB
„smart endpoints
and dumb pipes”

11. Disclaimer: I do not advertise event-driven
microservices as silver bullet!
Only use it when appropriate.
Handle with care!

12. Distributed systems

13. You need some safe harbors
and strategies to sail the
wild ocean

14. Microservices Event Driven & Reactive Domain Driven Design

15. Let‘s do an
example!
Assume you want
to build a Dash
button.

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

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

18. Collaboration using an eventflow
Order
placed
Payment
received
Goods
fetched
Goods
shipped
InventoryPayment ShippingShop

19. Great!

20. Great?

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

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

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

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

25. Order context
Payment
Retrieve
payment
Order
placed Order

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

27. Business Capabilities
Order
placed
Shop Payment ShippingInventory
Payment
received
Goods
fetched
Goods
shipped
Order
Order
completed
Retrieve
payment
Fetch
goods
Ship
goods

28. Quality Criteria: Changability
VIP customers can order with
invoice (and pay later)

29. Changability with pure event-chain
Order
placed
Payment
received
Goods
fetched
Goods
shipped
InventoryPayment ShippingShop
If VIP
customer
If not VIP
customer
Order
billed
Billing
If VIP
customer
VIP customers can order with
invoice (and pay later)

30. Changability with Event Command Transformation
Order
placed
Shop Payment ShippingInventory
Payment
received
Goods
fetched
Goods
shipped
Order
Order
completed
VIP customers can order with
invoice (and pay later)
Change how
to issue
commands

31. Quick demo
http://github.com/flowing/

32. Now back to real-life

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

34. Long running flows
require persistent state

35. How to implement?

36. State in entity
More alternatvies in my blog: https://blog.bernd-ruecker.com/
how-to-implement-long-running-flows-sagas-business-processes-or-similar-3c870a1b95a8

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

38. The 7 sins of workflow
3
4
6
5
7
http://blog.bernd-ruecker.com/
No state machine
Homegrown
state machine

39. Think about subsequent requirements
Monitoring &
Operations
Visibility
Versioning
Time &
Timeouts
Domain
Language
Performance &
Scaling

40. Process Manager
• Do event command transformation
• Handle state for long running flows

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

42. Logic remains in normal code

43. Tools provide persistent state, visibility and much more
+

44. On top: visbility
Payment
Retrieve
payment
Order
placed Order

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

46. Smells like
„BPM“?

47. The 7 sins of workflow
Homegrown
engine
BPM monolith
No engine Wrong engine Wrong usage
http://blog.bernd-ruecker.com/
4 5
7
3

48. The end-to-end process?

49. Don‘t do a „BPM monolith“ when using Microservices!
Order Feedback
Inventory
Payment

50. Payment
Local flows in the bounded contexts
Order

51. Multiple engines
Payment
Order
engine
engine
…
Inventory
Shipping
…
engine

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

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

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

56. Define flows programatically or graphically

57. Productive development and testing

58. Developer
friendly

59. Big challenges for
developers ahead!

60. Error and timeout handling

61. Handling complex scenarios

62. Demo
http://github.com/flowing/

63. Demo architecture
InventoryPaymentOrder Shipping
H2
Shop Monitor
Camunda
Webapp
on Tomcat
for demo in single Java VM for simplicity
https://github.com/flowing/flowing-retail/

64. Lightweight state machines or
workflow engines are not evil!
They do help you solving some really
hard coding problems.
These problems become more and
more frequent every day.

65. https://www.infoq.com/articles/microservice-event-choreographies

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

67. Thank you!