iSAQB Software Architecture Gathering 2023: How Process Orchestration Increases Agility Without Harming Architecture
•
1 like•74 views
This document discusses process orchestration and how it can increase agility without harming architecture. It begins by defining orchestration as command-driven communication and choreography as event-driven communication. It argues that while choreography allows for easy initial development, it can lead to technical debt over time by losing sight of larger business processes. Orchestration embraces asynchronicity and long-running processes to better model domain logic and responsibilities. This allows placing processes within service boundaries rather than having a few "god services". The document advocates balancing both orchestration and choreography based on responsibility and direction of coupling. It also suggests a center of excellence can help provide infrastructure while individual domains focus on solution delivery.
Recommended
Recommended
More Related Content
Similar to iSAQB Software Architecture Gathering 2023: How Process Orchestration Increases Agility Without Harming Architecture
Similar to iSAQB Software Architecture Gathering 2023: How Process Orchestration Increases Agility Without Harming Architecture (20)
More from Bernd Ruecker
More from Bernd Ruecker (20)
Recently uploaded
Recently uploaded (20)
iSAQB Software Architecture Gathering 2023: How Process Orchestration Increases Agility Without Harming Architecture
- 1. How Process Orchestration Increases Agility Without Harming Architecture @berndruecker
- 2. Choreography is great! Photo by Lijian Zhang, under Creative Commons SA 2.0 License
- 3. What we wanted Photo by Lijian Zhang, under Creative Commons SA 2.0 License and Wikimedia Commons / CC BY-SA 4.0 @berndruecker
- 6. Phil Calcado at QCon NYC 2019
- 7. Notification Checkout Payment Inventory Shipment @berndruecker Pinball Machine Architecture „What the hell just happened?“ @berndruecker
- 9. Why is it so tempting? Service A Event Bus A B Service B C Service C D E F Service D G Service … Service … Service … Service … Service … Service … Service … @berndruecker
- 10. Why is it so tempting? Service A Event Bus A B Service B C Service C D E F Service D G Service … Service … Service … Service … Service … Service … Service … Adding is easy! You can „buy“ a shorter initial time-to-value by choreography. It yields in technical debt. @berndruecker
- 11. Peer-to-peer event chains Checkout Payment Inventory Shipment Order placed Payment received Goods shipped Goods fetched Fetch the goods before the payment @berndruecker
- 12. Peer-to-peer event chains Checkout Payment Inventory Shipment Fetch the goods before the payment Goods fetched Order placed Payment received Goods shipped @berndruecker
- 13. 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
- 14. 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
- 15. 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
- 16. Order Fulfillment Extract the domain logic around order fulfillment Checkout Payment Inventory Shipment Payment received Order placed Retrieve payment @berndruecker
- 17. Order Fulfillment Decide about responsibility Checkout Payment Inventory Shipment Payment received Order placed Retrieve payment @berndruecker This is choreography This is orchestration
- 18. My definition Orchestration = command-driven communication Choreography = event-driven communication
- 19. Definitions Event = Something happened in the past. It is a fact. Sender does not know who picks up the event. Command = Sender wants s.th. to happen. It has an intent. Recipient does not know who issued the command.
- 20. Order It is not about the protocol! Checkout Payment Inventory Shipment Order placed Retrieve payment It can still be messaging! @berndruecker
- 21. Communication vs. Collaboration Style Communication Style Synchronous Blocking Asynchronous Non-Blocking Collaboration Style Command-Driven Event-Driven Example REST Messaging (Queues) Messaging (Topics) Feedback Loop HTTP Response Response Message - Pizza Ordering via Phone Call E-Mail Twitter This is not the same! See https://www.slideshare.net/BerndRuecker/jcon-2021-loosely-or-lousily-coupled
- 22. Order Fulfillment Checkout Payment Inventory Shipment Orchestration can be stateful / long running This orchestration requires state @berndruecker
- 24. mail@berndruecker.io @berndruecker http://berndruecker.io/ Bernd Ruecker Co-founder and Chief Technologist of Camunda
- 26. Glue code (e.g. Java) https://github.com/berndruecker/flowing- retail/blob/master/kafka/java/order- zeebe/src/main/java/io/flowing/retail/kafka/or der/flow/FetchGoodsAdapter.java
- 28. Using a workflow engine Workflow Engine Scheduler Durable State Glue Code Whatever you need… Workflow Definition Workflow Engine: Is stateful Can wait Can retry Can escalate Can compensate Provides visibility
- 29. Now it is easy to change the orchestration logic @berndruecker
- 30. Processes are domain logic and live inside service boundaries @berndruecker
- 31. Processes are domain logic and live inside service boundaries @berndruecker Orchestration does not need to be central
- 33. ? Event Command Message Record Event Fact, happened in the past, immutable Intend, Want s.th. to happen, The intention itself is a fact
- 34. ? Event Command Message Record Event
- 35. Commands in disguise The Customer Needs To Be Sent A Message To Confirm Address Change Event Send Message Wording of Sender Wording of recipient
- 36. Checkout Order Payment Event-driven: Decision to couple is on the receiving side Command-driven Decision to couple is on the sending side Direction of dependency Retrieve Payment Order placed Payment received Direction of dependency
- 37. Coupling
- 38. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid
- 39. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid
- 40. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid Temporal Coupling Service depends on availability of other services Synchronous blocking communication Reduce or manage
- 41. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid Temporal Coupling Service depends on availability of other services Synchronous blocking communication Reduce or manage This is influenced with the communication or collaboration style Can be also reduced by other means than asynchronous messaging!
- 42. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid Temporal Coupling Service depends on availability of other services Synchronous blocking communication Reduce or manage Deployment Coupling Multiple services can only be deployed together Release train Typically avoid, but depends
- 43. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid Temporal Coupling Service depends on availability of other services Synchronous blocking communication Reduce or manage Deployment Coupling Multiple services can only be deployed together Release train Typically avoid, but depends
- 44. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid Temporal Coupling Service depends on availability of other services Synchronous blocking communication Reduce or manage Deployment Coupling Multiple services can only be deployed together Release train Typically avoid, but depends Domain Coupling Business capabilities require multiple services Order fulfillment requires payment, inventory and shipping Unavoidable unless you change business requirements or service boundaries
- 45. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid Temporal Coupling Service depends on availability of other services Synchronous blocking communication Reduce or manage Deployment Coupling Multiple services can only be deployed together Release train Typically avoid, but depends Domain Coupling Business capabilities require multiple services Order fulfillment requires payment, inventory and shipping Unavoidable unless you change business requirements or service boundaries
- 46. Customer Created Sam Newman: Building Microservices
- 47. Customer Onboarding is a mix! Orchestration Orchestration Orchestration Choreography
- 48. Order Order Notification Notification Payment Send legal docs Payment received Order placed Send email It is all about responsibility!
- 49. Long running capabilities are essential to design good service boundaries (= a good architecture) @berndruecker
- 53. Example Order Fulfillment Payment If the credit card was rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Rejected @berndruecker
- 54. Example Order Fulfillment Payment If the credit card was rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Rejected @berndruecker A few smart god services tell anemic CRUD services what to do Sam Newmann
- 55. Payment failed Who is responsible to deal with problems? Order Fulfillment Payment If the credit card was rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Payment received @berndruecker
- 56. Payment failed (Potentially) long running services Order Fulfillment Payment Credit Card Retrieve Payment Rejected Payment received @berndruecker
- 57. retrievePayment HTTP 200 OK HTTP 202 ACCEPTED Payment Happy case: Synchronous response Otherwise: asynchronous Embrace asynchronicity
- 58. Designing good service boundaries Order Fulfillment Payment Credit Card @berndruecker
- 59. Business Unit or Domain Business Unit or Domain Business Unit or Domain Process Automation Center or Excellence Solution Delivery Solution Delivery Solution Delivery Solution Delivery Solution Delivery enable Provide custom connectors Provide process orcherstration as a service …
- 60. @berndruecker
- 62. Photo by born1945, available under Creative Commons BY 2.0 license.
- 63. Golden Paths https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/ “We found that rumour-driven development simply wasn’t scalable” @berndruecker
- 64. https://backstage.io/ (OSS, Made with ❤️ at Spotify) @berndruecker
- 65. Photo by born1945, available under Creative Commons BY 2.0 license. Domain A Domain B
- 66. # Orchestration != central # Choreography != decoupled # Orchestration = Command-driven # Choreography = Event-driven # You need to balance both! # It is about responsibility and the direction of coupling # You need long running capabilities to design good boundaries # Some central capability for providing infrastructure helps @berndruecker
- 67. Want To Know More?