Slides from my talk at the GOTO meetup in Stockholm on 5th of April 2017. The talk is about the flow in microservices, so how a bunch of loosely coupled microservices can fulfill an overall business goal.

1. Let your microservices flow!
bernd.ruecker@camunda.com
With thoughts from http://flowing.io
@berndruecker | @martinschimak

2. Assume you want
to build a better
Amazon Dash
button

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

4. How to build?

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. Event driven microservices
Microservice Microservice Microservice
A B C
Eventbus

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

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

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

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

11. Yeah.

12. So let‘s build that…

13. Sample microservices
Inventory service
Handles Stock,
Reserviations and
physical handling
of goods
Payment service Handles Payment
Shipping service
Manage
shipments &
labels for logistic
providers

14. Eventflow
Order
Placed
Payment
Received
Goods
Picked
Goods
Shipped
InventoryPayment ShippingShop

15. Implementation

16. Let‘s zoom in the payment service
Payment service
order
placed
payment
received

17. Let‘s zoom in the payment service
Payment service
order
placed
payment
received
The payment service
has to listen to
„order placed“ event

18. De-coupling?
Payment service
order
placed
service
fullfilled
…
Whenever a new service requires
payment, the payment has to be
changed
Payment has to know all possible
events that trigger a payment
subscription
confirmed

19. New business requirements
Order
Placed
Payment
Received
Goods
Picked
Goods
Shipped
InventoryPayment ShippingShop
VIP customers can order with
invoice (and pay later)

20. New business requirements
Order
Placed
Payment
Received
Goods
Picked
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

21. Event Command Transformation
Payment Service
do
payment
order
placed Transformation
Command
Something has to happen
in the future
1 recipient
Event
Something has happend
in the past
0..n recipients

22. This calls for an order service
Payment service
do
payment
order
placed Order service

23. Microservices
Inventory service
Payment service
Order service
Does event
command
transformation
for orders
Shipping service

24. Shipment
Service
Inventory
Service
Payment
Service
Event Command Transformation
do
payment
order
placed
Order
Service
payment
received
pick
goods
goods
picked
ship
goods
goods
shipped
order
delivered
Order
Service
Order
Service
Order
Service

25. Smeels like a
central ESB?
http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html

26. No! Far from it!
Inventory service
Payment service
Order service
Not in the pipe
but in a domain
related service.
Probably
simple code.
Shipping service

27. Easiest implementation
if (event.equals("order placed")) {
issueCommand("do payment");
}

28. Implementation (with event command transformation)

29. But…

30. The example process
receive
shipment
place
order
manual approval
in case of risky orders
risk
check
payment delivery

31. Requirements
receive
shipment
place
order
manual approval
in case of risky orders
risk
check
payment delivery
Long running,
requires state handling
Service collaboration,
potentially long running

32. Long running flows have state

33. State in entity

34. Or a seperate state entity

35. State machine, e.g. Camunda
http://camunda.org/

36. State machine, e.g. Camunda
http://camunda.org/

37. Tools provide persistent state, visibility and more

38. The 7 sins of workflow and Java
No engine Wrong engine
3
4
6
5
7
http://blog.bernd-ruecker.com/
2

39. The 7 sins of workflow and Java
Homegrown
engine
No engine Wrong engine
3
4
6
5
7
http://blog.bernd-ruecker.com/

40. The homegrown engine
©kallejipp/photocase.com
Own DSL, parsing, graphical representation,
modeler, persistence, escalation, version
management, tooling, …
Whole teams maintaining something that
always lacks behind

41. Netflix also recognized

42. Camunda uses BPMN
Worldwide adopted industry standard

43. Smells like
„BPM“?

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

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

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

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

48. Bernd Rücker
Co-founder Camunda
Consultant & Evangelist
> 10+ years workflow
http://bernd-ruecker.com/
bernd.ruecker@camunda.com
Camunda
Open source vendor
Berlin & San Francisco
> 60 employees
www.camunda.org

50. Define flows programatically or graphically
Todo…

51. Productive development and testing

52. Developer
friendly

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

54. You are not forced to violate the microservice ownership!
Order Feedback
Inventory
Payment

55. Payment
Overall choreography with local flows
Order
Eventbus

56. Lightweight and embeddable engines
Engine must be
• easy to use
• developer friendly
also in the scope of multiple
scopes/aggregates/services
• technically
• license model
Payment
Order
engine
engine
…
…
…
…
engine

57. It is about visibility!

58. It is about ubiquitos language!

59. Models are running code!

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

62. Live
Demo

63. Demo architecture
InventoryPaymentOrder Shipping
H2
Shop Monitor
Camunda
Webapp
on Tomcat
for demo in single Java VM for simplicity

64. Screenshots

65. Screenshots

66. We want to reserve
goods even before we
received the payment.

67. Adjust the flow

68. Changes
Inventory service
Payment service
Order service
Shipping service
must provide
reservation
servicereserve goods at
right moment
Listen to goods
reserved instead
of order created.
Listen to order
created.
With event command
transformation
Without

69. VIP customers can
order with invoice
(and pay later)

70. Adjusted flow

71. Required changes
Inventory service
Payment service
Order service
Shipping service
Invoice service
skip payment, but
add open invoice
Listen to order
created VIP or
payment received
(non VIP).
Listen to order
created (VIP).

72. When a customer
cancels, we want to
win him back!

73. Required changes
Inventory service
Payment service
Order service
Shipping service
Listen to
appropriate
events, no change
anywhere else
Winback service

74. We need more
advanced stuff – can
your flows do this?

75. Timeouts
…after two weeks
pricing is not binding
any more

76. Compensation
…in case of errors in
error handling pay the
money back to the
customer

77. Summary
• Microservices and event driven
architecture go well together
• You need an event command
transformation
• If the translation is stateful,
consider using an appropriate
engine
• Modern lightweight engines
foster and not hinder these
architectures

78. Is it really for me?
Isn‘t all of that just for FANG?

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

80. Thank you! Any questions?

81. Coding exercise

82. Idea

83. Sorry for any bugs!

84. Participant
Participant
The setup
Cloud Foundry
Java application
H2
Participant
H2
REST

85. Participant
Participant
Cloud Foundry
Java application
H2
Participant
REST
The setup

86. Participant
Participant
The setup
Cloud Foundry
Java application
H2
Participant
H2
REST

87. Lab:
https://github.com/berndruecker/camunda-interactive-lab
CF Endpoint:
https://camunda-interactive-lab.cfapps.io/
You can test the endpoint by e.g. checking for running instances:
https://camunda-interactive-lab.cfapps.io/rest/engine/default/process-instance