@berndruecker#VoxxedVienna
Because your business is
more complex than *
* Some big video streaming company
bernd.ruecker@camunda.com
With thoughts from http://flowing.io
@berndruecker | @martinschimak

FAMGA

FANG

Tech stack
https://www.slideshare.net/RaminForood/platform-data-technologies-at-netflix
No
orchestration.

Orchestration

Netflix recognized challenges in orchestration

Let‘s do some groundwork before we
dive into orchestration…

System complexity increases dramatically
Warehouse
System
Logistics
Platform
Taxi
System
Travel
Platform
Insurance
System
Insurance
Platform
Heating with
temperature
sensor
Smart Heating
(Cloud
controlled)
…
…

Helpful paradigms
Microservices Event Driven & Reactive Domain Driven Design

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

Event driven microservices
Microservice Microservice Microservice
A B C
Eventbus

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

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

Compare to SOA
Service Service
A C
ESB
„smart endpoints
and dumb pipes”

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

Yeah.

Example: Simple order handling

pay receive
shipment
place
order
I want to buy this!
I am happy!

Sample Microservices
Inventory Service
Handles Stock,
Reserviations and
physical handling
of goods
Payment Service Handles Payment
Shipping Service
Manage
shipments &
labels for logistic
providers

Eventflow
Order
Placed
Payment
Received
Goods
Picked
Goods
Shipped
InventoryPayment ShippingShop

Implementation

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

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

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

Martin Fowler also recognized
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

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

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

Microservices
Inventory service
Payment service
Order service
Does event
command
transformation
for orders
Shipping 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

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

No! Far from it!
Inventory service
Payment service
Order service
Might be
implemented in
simple Java
Shipping service

Order service does the orchestration

Implementation (with event command transformation)

Some things in life are slow
do
payment
order
placed
payment
received
pick
goods
goods
picked
ship
goods
goods
shipped
order
delivered
Order
Service
Long
Running
Long
Running
Long
Running
Long
Running

You also have to handle state.

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

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

ToolsState Visibility
[ Orchestration | Workflow | BPM ] Engine

Order example in BPMN*
*BPMN = ISO standard for modeling and execution
in this
context
means:

Payment example

Paymentservice
Orchestration is part of the microservices!
Orderservice
Eventbus

It does not have to be one monlithic process
Hint: This might work well if your company is structured to
have this one clear process owner for this process.

Microservice vs. BPM community

Requirement: lightweight and embeddable engine
Engine must be
• easy to use
• developer friendly
also in the scope of microservices
• technically
• license model
Payment service
Order service
engine
engine
…
…
…
…
engine

Yes – that‘s possible!

Live
Demo

Architecture
Inventory
service
Payment
service
Order
service
Shipping
service
H2
Shop Monitor
Camunda
Webapp
on Tomcat
for demo in single Java VM for simplicity

Screenshots

Screenshots

And synchronous communication?

Communication between Microservices
Microservice Microservice
Microservice
A B
C
e.g. REST
You need to handle
outtages (wait, retry, …)

Change scenarios

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

Changes
Inventory service
Payment service
Order service
Shipping service
must provide
reservation
servicereserve goods at
right moment

BPMN

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

VIP customers can
order with invoice
(and pay later)

Required changes
Inventory service
Payment service
Order service
Shipping service
Invoice service
skip payment, but
add open invoice

Responsibility of order service

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

We need more cool
stuff – can BPMN do
this?

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

Timeouts
…after two weeks
pricing is not binding
any more

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

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

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

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

With thoughts from http://flowing.io
@berndruecker | @martinschimak

https://github.com/flowing

Slides online at http://bernd-ruecker.com

Thank you! Any questions?