Download as PDF, PPTX
Uploaded byBernd Ruecker
iSAQB Software Architecture Gathering 2023: How Process Orchestration Increases Agility Without Harming Architecture
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.
More Related Content
Similar to iSAQB Software Architecture Gathering 2023: How Process Orchestration Increases Agility Without Harming Architecture
![Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]](https://cdn.slidesharecdn.com/ss_thumbnails/codedagentsdeck-251215155422-5497c599-thumbnail.jpg?width=640&height=640&fit=bounds)
iSAQB Software Architecture Gathering 2023: How Process Orchestration Increases Agility Without Harming Architecture
- 1. How Process Orchestration Increases Agility WithoutHarming Architecture @berndruecker
- 2. Choreography is great! Photoby Lijian Zhang, under Creative Commons SA 2.0 License
- 3. What we wanted Photoby Lijian Zhang, under Creative Commons SA 2.0 License and Wikimedia Commons / CC BY-SA 4.0 @berndruecker
- 4.
- 5.
- 6. Phil Calcado atQCon NYC 2019
- 7. Notification Checkout Payment Inventory Shipment @berndruecker Pinball Machine Architecture „Whatthe hell just happened?“ @berndruecker
- 8.
- 9. Why is itso 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 itso 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 Fetchthe goods before the payment @berndruecker
- 12. Peer-to-peer event chains Checkout Payment Inventory Shipment Fetchthe goods before the payment Goods fetched Order placed Payment received Goods shipped @berndruecker
- 13. The danger isthat 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 isthat 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 isthat 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 domainlogic 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 Thisis choreography This is orchestration
- 18. My definition Orchestration =command-driven communication Choreography = event-driven communication
- 19. Definitions Event = Somethinghappened 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 notabout the protocol! Checkout Payment Inventory Shipment Order placed Retrieve payment It can still be messaging! @berndruecker
- 21. Communication vs. CollaborationStyle 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 bestateful / long running This orchestration requires state @berndruecker
- 23.
- 24.
- 25.
- 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 workflowengine 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 iseasy to change the orchestration logic @berndruecker
- 30. Processes are domainlogic and live inside service boundaries @berndruecker
- 31. Processes are domainlogic and live inside service boundaries @berndruecker Orchestration does not need to be central
- 32.
- 33. ? Event Command Message RecordEvent Fact, happened in the past, immutable Intend, Want s.th. to happen, The intention itself is a fact
- 34.
- 35. Commands in disguise TheCustomer 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: Decisionto 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.
- 38. Types of Coupling Typeof coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid
- 39. Types of Coupling Typeof coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid
- 40. Types of Coupling Typeof 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 Typeof 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 Typeof 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 Typeof 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 Typeof 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 Typeof 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 isa mix! Orchestration Orchestration Orchestration Choreography
- 48.
- 49. Long running capabilities areessential to design good service boundaries (= a good architecture) @berndruecker
- 50.
- 51.
- 52.
- 53. Example Order Fulfillment Payment If the credit cardwas rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Rejected @berndruecker
- 54. Example Order Fulfillment Payment If the credit cardwas 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 responsibleto 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 runningservices Order Fulfillment Payment Credit Card Retrieve Payment Rejected Payment received @berndruecker
- 57. retrievePayment HTTP 200 OK HTTP202 ACCEPTED Payment Happy case: Synchronous response Otherwise: asynchronous Embrace asynchronicity
- 58. Designing good serviceboundaries Order Fulfillment Payment Credit Card @berndruecker
- 59. Business Unit or Domain BusinessUnit 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.
- 61.
- 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 foundthat rumour-driven development simply wasn’t scalable” @berndruecker
- 64. https://backstage.io/ (OSS, Madewith ❤️ 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 KnowMore?
- 68.
- 69.