SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 30 day free trial to unlock unlimited reading.
Slides from a talk held at WJAX Munic on 9th of November (and some other meetups later in November) about how to tackle collaboration of microservices.
Most of the talk was live coding, the respective code is here: https://github.com/flowing/flowing-retail.
Slides from a talk held at WJAX Munic on 9th of November (and some other meetups later in November) about how to tackle collaboration of microservices.
Most of the talk was live coding, the respective code is here: https://github.com/flowing/flowing-retail.
1.
(Micro-)service collaboration
WJAX, Munic, 08th of November 2017
mail@bernd-ruecker.com | @berndruecker
With thoughts from http://flowing.io
@berndruecker | @martinschimak
2.
Simplified example:
dash button
Photo by 0xF2, available under Creative Commons BY-ND 2.0
license. https://www.flickr.com/photos/0xf2/29873149904/
3.
Basic idea of dedicated, autonomous (micro-) services
Checkout
Payment
Inventory
Shipment
Dedicated Application Processes
Dedicated Persistence Backends
Dedicated Development Teams
4.
But: A lot of them…
Checkout
Payment
Inventory
Shipment
The complexity
moves to the
collaboration of the
services
21.
Synchronous communication
is the crystal meth of
distributed programming
Todd Montgomery and Martin Thompson
in “How did we end up here” at GOTO Chicago 2015
22.
Better asynchronous communication?
That typically means: messaging
systems.
26.
Design
for
failure!
2356143672_f5f88797d5_b.jpg
Photo by GalaticWanderlust, available under Creative Commons BY 2.0 license.
27.
In general, application developers simply do
not implement large scalable applications
assuming distributed transactions. When
they attempt to use distributed transactions,
the projects founder because the
performance costs and fragility make them
impractical. Natural selection kicks in…
28.
Business
transactions
can work
without
two phase
commit!
Photo by Gerhard51, available under Creative Commons CC0 1.0 license.
30.
Request/Response: temporally coupled services
Checkout
Payment
Inventory
Shipment
„The button blinks green
if we can ship the item
within 24 hours!“
Request Response
31.
Events: temporal decoupling with read models
Checkout
Payment
Inventory
Shipment
„The button blinks green
if we can ship the item
within 24 hours!“
Events are facts about
what happened (in the past)
Good
Fetched
Good
Stored
Read
Model
33.
Events: peer-to-peer event choreographies
Checkout
Payment
Inventory
Shipment
Order
placed
Payment
received
Good
shipped
„When the button is pressed, an
order is placed - and fulfilled!“
Good
fetched
34.
Events: peer-to-peer event choreographies
Please fetch
the goods
before waiting
for payment
Some
customers can
pay via invoice
…
Checkout
Payment
Inventory
Shipment
Good
fetched
Order
placed
Payment
received
Good
shipped
35.
Events can increase coupling*
*e.g. complex peer-to-peer event chains
36.
Extract the end-to-end responsibility
Order
Checkout
Payment
Inventory
Shipment
Order
placed
Retrieve
payment
Commands have an
intent about what needs
to happen in the future
Please fetch
the goods
before waiting
for payment
Some
customers can
pay via invoice
Payment
received
Retrieve
payment
40.
Wrap-up
# Understand complexity of distributed systems
Sync/async, request/response, event-driven
# Know strategies and tools to handle it
e.g.Circuit breaker (Hystrix)
State machine for visual flow, wait, timeout,
retry and compensation (Camunda, Zeebe)