Balancing Choreography and Orchestration • Bernd Rücker • GOTO 2020
Vložit
- čas přidán 27. 07. 2024
- This presentation was recorded at GOTOpia November 2020. #GOTOcon #GOTOpia
gotopia.eu
Bernd Rücker - Co-founder and Chief Technologist of Camunda and co-author of “Real-Life BPMN"
ABSTRACT
These days, many teams favor loose coupling, isolation and autonomy of services and therefore typically opt for event-driven and reactive architectures, using a communication pattern known as choreography.
Bernd Rücker believes that choreography is beneficial in some situations, but that it is far from the holy grail of integration.
In some scenarios, it increases coupling, often accidentally and to a dangerous degree. Orchestration is a better choice for some situations but is often bashed for introducing tight coupling. Bernd will debunk some of these myths and show how orchestration can even reduce coupling in some situations and work in an asynchronous, message-driven fashion [...]
TIMECODES
00:00 Intro
01:23 Orchestration vs choreography
03:47 Example
04:25 Synchronous call chains
05:46 Asynchronous call chains
06:22 Choreography or orchestration?
07:49 Event-driven
09:31 P2P event chains
16:10 Decide about responsibility
19:56 Stateful orchestration
22:15 Glue code e.g. Java
23:07 Using a workflow engine
24:20 Challenge: Command vs event
31:04 Your IT architecture
31:44 Summary
Download slides and read the full abstract here:
gotopia.eu/november-2020/sess...
RECOMMENDED BOOKS
Bernd Rücker • Practical Process Automation • amzn.to/3cs3BSH
Aaron Rinehart • Security Chaos Engineering • www.verica.io/sce-book
Nora Jones & Casey Rosenthal • Chaos Engineering • www.verica.io/book
Nora Jones & Casey Rosenthal • Chaos Engineering • amzn.to/3hUmuAH
Mikolaj Pawlikowski • Chaos Engineering • amzn.to/2SQ5Olf
Russ Miles • Learning Chaos Engineering • amzn.to/3hCiUe8
Murphy, Beyer, Jones & Petoff • Site Reliability Engineering • amzn.to/2Vg6Mbr
/ gotocon
/ goto-
/ gotoconferences
#EventDrivenArchitecture #SoftwareArchitecture #EventDriven #PinballMachineArchitecture #EventChains #StatefulOrchestration #Java #WorkflowEngine #Monolith #Microservices #ChaosEngineering
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
czcams.com/users/GotoConf... - Věda a technologie
Another way to put it:
Orchestration - you *know* what happens *next*
Choreography - you *react* to what happened *before*
wow. i never thought of this. well said sir.
define "you"
It's even better than just great. It's brilliant. Years if even-driven architecture in 30 minutes video.
Nice, it sounds brief:
Orchestration = command-driven communication
Choreography = event-driven communication
That's it!
It's the best explanation ever. Thanks Bernd !
Fantastic presentation! Thank you for sharing your explanation 🙏
Thanks as always GOTO. Always interesting topics. See you soon!
I wrote an article ones, where Choreography and Orchestration are persons debating who is better :) but, always to see someone's point of view on the same topic, especially when mine was a bit different until the end of this talk!
That order fulfilment service is nothing else but saga (Saga Pattern) implemented with a workflow engine.
Exactly.
Very good explanation.
Awesome explanation, thanks!
Orchestration: process knowledge is centralized.
Choreography = process knowledge is distributed.
Orchestration introduces a possible Single Point of Failure.
Choreography implies distribution, so it only makes sense in an event-driven setup, as to avoid the distributed monolith.
very cool, thank you
Great explanation.
VERY GREAT TALK!
very good
What's that video of the meet up guy saying they're suffering from Pinball Architecture? I'd like to watch it
Well explained
fantastic, thank you!
To start to have understanding of emergent behaviors on event based choreography, The subscribers for the event should let know the system for what business process that they are subscribing the event, e.g we have a susbscrption service (say a wrapper around some messaging like kafka), the susbscribers call this service "event they wish to subscribe" and "the business process", Now in your subscription registry you have all the information and sequence.
To identify where we need orchestration is to look for services that publishes an event and also subscribes to the result of event, e.g In financial context lets say the "audit" services publishes the audit changed event, and also susbscribe to the "audit notification sent" event it indicates that "audit" is sending the event in disguise, this should be a "notify audit" command rather.
While both these models work, the intention becomes clear and control becomes more prominent when expressed as command.
you could present your own case, rather than criticize someone else's material.