Embed Size (px)
Citation preview
Distributed Orchestration of Microservices
[email protected] | @berndruecker
Co-Founder & Developer Advocate CamundaWith thoughts from http://flowing.io@berndruecker | @martinschimak
Co-founder and Developer Advocate ofCamunda
Berlin, Germany
[email protected]@berndruecker
Bernd Ruecker
3 common hypotheses I check today:
# Events decrease coupling# Orchestration needs to be avoided# Workflow engines are painful
Simplified example:dash button
Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/29873149904/
Three steps…
Who is involved?
Checkout
Payment
Inventory
Shipment
Autonomous (micro-)services
Checkout
Payment
Inventory
Shipment
Dedicated Application Processes
Dedicated infrastructure
Dedicated Development Teams
Events decrease coupling
Request/response: temporal coupling
Checkout
Payment
Inventory
Shipment
RequestResponse
The button blinks if we canship within 24 hours
Temporal decoupling with events and read models
Checkout
Payment
Inventory
Shipment
GoodStored
Read Model
GoodFetched
The button blinks if we canship within 24 hours
*Events are facts about what happened (in the past)
Events can decrease coupling*
*e.g. decentral data-management, read models, extract cross-cutting aspects
Peer-to-peer event choreography
Checkout
Payment
Inventory
Shipment
Order placed
Payment received
Goodsshipped
Goodsfetched
Peer-to-peer event choreography
Checkout
Payment
Inventory
Shipment
Order placed
Payment received
Goodsshipped
Goodsfetched
Fetch the goodsbefore thepayment
Peer-to-peer event choreography
Checkout
Payment
Inventory
Shipment
Fetch the goodsbefore thepayment
Goodsfetched
Order placed
Payment received
Goodsshipped
Peer-to-peer event choreography
Checkout
Payment
Inventory
Shipment
Fetch the goodsbefore thepayment
Customers canpay via invoice
Goodsfetched
Order placed
Payment received
Goodsshipped
…
Photo by born1945, available under Creative Commons BY 2.0 license.
Order
Extract the end-to-end responsibility
Checkout
Payment
Inventory
Shipment
*Commands have an intent about what needs to happen in the future
Order placed
Paymentreceived
Retrievepayment
Commands help to avoid(complex) peer-to-peer event chains
Orchestration needs to be avoided
Smart ESB-like middleware
Checkout
Payment
Inventory
Shipment
Order
Order placed
Payment received
Goodfetched
Goodshipped
Dumb pipes
Checkout
Payment
Inventory
Shipment
Order
Smart endpoints and dumb pipes
Martin Fowler
Danger of god services?
Checkout
Order
A fewsmart god services tellanemic CRUD services what to do
Sam Newmann
Payment
Inventory
Shipment
Danger of god services?
Checkout
Payment
Inventory
Shipment
Order
A fewsmart god services tellanemic CRUD services what to do
Sam Newmann
A god service is only createdwith bad API design!
Who is responsible to deal with problems?
Order Payment
RetrievePayment
Who is responsible to deal with problems?
Order PaymentCreditCard
RetrievePayment
Who is responsible to deal with problems?
Order PaymentCreditCard
RetrievePayment
Rejected
Who is responsible to deal with problems?
Order Payment
Client of dumb endpoints easily become a god services.
If the creditcard was
rejected, thecustomer canprovide new
details
CreditCard
RetrievePayment
RejectedRejected
Paymentcanceled
Who is responsible to deal with problems?
Order Payment
If the credit card was
rejected, the customer can provide new
details
CreditCard
RetrievePayment
Rejected
Paymentreceived
Paymentcanceled
Who is responsible to deal with problems?
Order Payment
Clients of smart endpoints remains lean.
If the credit card was
rejected, the customer can provide new
details
CreditCard
RetrievePayment
Rejected
Paymentreceived
Smart endpoints are potentially long-running
Photo by Tookapic, available under Creative Commons CC0 1.0 license.
„There was an errorwhile sending your
boarding pass“
Check-in
Web-UI
Me
Current situation
Check-in
Barcode Generator
Web-UI
Me
Output Mgmt
Current situation
Check-in
Barcode Generator
Web-UI
Me
Output Mgmt
Current situation
Check-in
Barcode Generator
Web-UI
Me
Output Mgmt
Current situation – the bad part
Check-in
Barcode Generator
Web-UI
Me
Output Mgmt
Current situation – the bad part
StatefulRetry
Check-in
Barcode Generator
Web-UI
Me
Output Mgmt
Possible situation – much better!
Check-in
Barcode Generator
Web-UI
Me
Output Mgmt
Possible situation – much better!
StatefulRetry
Check-in
Barcode Generator
Web-UI
Me
Output Mgmt
StatefulRetry
Possible situation – much better!
The failurenever leavesthis scope!
Persist thing(Entity, Actor, …)
State machine orworkflow engine
Typicalconcerns
DIY = effort, accidentalcomplexity
Scheduling, Versioning, operating, visibility, scalability, …
Handling State
Workflow engines are painful
Complex, proprietary, heavyweight, central, developer adverse, …
Workflow engines, state machines
It is
relevantin modern
architectures
CADENCE
Silicon valleyhas recognized
Workflow engines, state machines
CADENCEWorkflow engines, state machines
CADENCE
also at scaleWorkflow engines, state machines
CADENCE
for todays demo
Workflow engines, state machines
Payment
The workflow engine handles state
CreditCardREST
Fallbacks increase resilience
CreditCard
PaymentREST
Distributedsystems
It is impossible todifferentiate certain
failure scenarios.
Independant ofcommunication style!
Service Provider
Client
One HTTP call introduces complexity you have to tackle!
CreditCard
PaymentREST
One HTTP call introduces complexity you have to tackle!
CreditCard
PaymentREST
Timeouts
Distributedsystems
Business transaction / compensation*
Living documentation for long-running behaviour
A visual HTML report for a specific test case
Do you prefer coded or graphical DSLs?
Bpmn.createExecutableProcess("order")//....sendTask("RetrievePayment").camundaClass(RetrievePaymentAdapter.class).receiveTask("PaymentReceived").message("PaymentReceivedEvent")//...
* BPMN - ISO notation for modeling andexecuting long-running processes and flows
Before mapping processes explicitly with BPMN, the truth was buried in the code and nobody knew what was going on.
Jimmy Floyd, 24 Hour Fitnesse
„
Workflows live inside service boundaries
Manigfold architecture options
https://blog.bernd-ruecker.com/architecture-options-to-run-a-workflow-engine-6c2419902d91
Lightweight workflow engines aregreat – don‘t DIY*
*e.g. enabling potentially long-running services, solving harddeveloper problems, can run decentralized
Zalando
Sales-Order and
Order-Fulfillment
via Camunda
for every order worldwide
Orders Q2-2017: 22,2 Mio.
Sales 2016: 3,6 Mrd. EUR
Growth 2016: 23%
Some code
InventoryPaymentOrder ShippingCheckout Monitor
https://github.com/flowing/flowing-retail/
Human Tasks
H2 H2
# Events decrease coupling: sometimesread-models, but no complex peer-to-peer event chains!
# Orchestration needs to be avoided: sometimesno ESB, smart endpoints/dumb pipes, important capabilities need a home
# Workflow engines are painful: some of themlightweight engines are easy to use and can run decentralized,they solve hard developer problems, don‘t DIY
Thank you!
[email protected]@berndruecker
https://bernd-ruecker.com
https://blog.bernd-ruecker.com
https://github.com/flowing
https://www.infoq.com/articles/events-workflow-automation With thoughts from http://flowing.io
@berndruecker | @martinschimak
Contact:
Slides:
Blog:
Code:
https://www.infoworld.com/article/3254777/application-development/3-common-pitfalls-of-microservices-integrationand-how-to-avoid-them.html
