Loosely or lousily coupled? Understanding communication patterns in modern architectures with Thomas Heinrichs | Kafka Summit London 2022
•
0 likes•456 views
Modern architectures consist of many distributed components or services, which shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now, is event streaming always the best approach, or when should you look at asynchronous messaging, or REST? What is best covered via Kafka? Where do you hit limits? What are the tradeoffs, and how does all of this influence coupling of your components? This talk will help you answer important questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.
Recommended
Recommended
More Related Content
Similar to Loosely or lousily coupled? Understanding communication patterns in modern architectures with Thomas Heinrichs | Kafka Summit London 2022
Similar to Loosely or lousily coupled? Understanding communication patterns in modern architectures with Thomas Heinrichs | Kafka Summit London 2022 (20)
More from HostedbyConfluent
More from HostedbyConfluent (20)
Recently uploaded
Recently uploaded (20)
Loosely or lousily coupled? Understanding communication patterns in modern architectures with Thomas Heinrichs | Kafka Summit London 2022
- 1. Loosely or Lousily Coupled? Understanding Communication Patterns in Micorservice Architectures By Thomas Heinrichs
- 2. About your speaker Thomas Heinrichs Developer Advocate @ Camunda Thomas.heinrichs@camunda.com @hafflgav Augsburg, Germany
- 3. What will you learn in this session? How you can make Pizza in a scalable fashion How orchestration differs from choreography What types of coupling to avoid or manage
- 4. Let’s talk about food!
- 5. How does ordering a Pizza work? Phone Call Email with feedback loop Email ■ Synchronous blocking communication ■ Feedback loop ■ Temporal coupling ■ Asynchronous non- blocking communication ■ No temporal coupling ■ No temporal coupliong ■ Asynchronous ■ With feedback loop Pizza Place You Phone Call Pizza Place You E-Mail Pizza Place You E-Mail Confirmation E-Mail
- 6. “ ■ Feedback Loop ■ != Result Pizza Place You E-Mail Confirmation E-Mail Pizza Delivery
- 7. Synchrounous blocking vs Scalable Pizza Making Synchronous blocking Scalable ■ Little Kebap store with only one person working ■ Reponsible for everything ■ Queues pile up easily ■ Separation of order, payment and preparation ■ Mixture of synchronous and asynchronous
- 8. Synchrounous blocking vs Scalable Pizza Making 8 Transitioning the example to the delivery service ■ The task of pizza making is long running ■ Synchronous blocking communication would not be feasible ■ Using a mixture of both enables better scalability and a clear communication to the customer ■ How is this coordinated? PUT /order Pizza Place You Pizza Delivery HTTP 202 Pizza Place You PUT /order HTTP 200 Pizza Delivery
- 9. How can we handle such a long running task? 9 A workflow engine provides long running capabilities
- 10. What does a workflow engine do? 10 Scheduler ■ Can wait ■ Can retry ■ Can escalate ■ Can compensate Workflow Definitions ■ Provides Visibility Durable State ■ Is stateful ■ Provides durable states
- 11. One process instance gets started. It is persisted in the workflow engine and „walks“ through the process model. @PUT retrievePayment() { result = workflowEngine. startProcessInstance('payment') if (result.hasEnded()) return 'paymentSucceeded' else return 'paymentSucceeded' } Your code to provide a REST endpoint Instance Id Process Definition Current State … …-7454 payment „Charge Credit Card“ … …-4571 payment „Charge Credit Card“ … Process Instance Table Durable state of workflow engine Your glue code to implement the REST call @Task('chargeCreditCard') chargeCreditCard() { ... restClient.put( 'http://creditCards/charge/', requestData) } Credit Card Service REST
- 12. “ 12 ■ But isn’t this Orchestration which couples everything much tighter? Let’s try to analyse this by having a more detailed look at it.
- 13. Command vs. event-based Communication ■ Command = Intent ■ Cannot be ignored ■ Independent of communication channel Command-based ■ Event = Fact ■ Sender cannot control what happens Event-based Pizza Place You I order this pizza OK – got it Pizza Place You „Hey – I am hungry!“
- 14. „Pizza Salmon is ready!“ I baked this pizza for Andrea. Please package it immediately and deliver it while it‘s hot!
- 15. “ 15 Definition of an Event ■ Something happened in the past. It is a fact. Sender does not know who picks up the event.
- 16. “ 16 Definition of a Command ■ Sender wants something to happen. It has an intent. Recipient does not know who issued the command.
- 17. Choreography vs Orchestration ■ Sombody ordered a Pizza ■ Pizza is ready Choreography ■ Getting a very specific command which Pizza for whom to prepare Orchestration Command Orchestrator
- 18. “ ■ Orchestration = command-driven communication ■ Choreography = event-driven communication
- 19. Switching examples to Order Fulfillment This is an Event Chain! Problem: ■ An event chain is invisible ■ Not explicit ■ Hard to figure our – especially in bigger architectures ■ Changing the sequence of steps is difficult! Checkout Payment Inventory Shipment Order placed Payment received Goods shipped Goods fetched
- 20. Switching examples to Order Fulfillment This is an Event Chain! Problem: ■ An event chain is invisible ■ Not explicit ■ Hard to figure out – especially in bigger architectures ■ Changing the sequence of steps is difficult! There are a lot of ressources about this problem. E.g. from QCon or even Martin Fowler. Checkout Payment Inventory Shipment Order placed Payment received Goods shipped Goods fetched
- 21. Orchestration and Choreography Checkout Payment Inventory Shipment Order placed Payment received Retrieve Payment Order Fulfillment Choreography and orchestration – event and commands can be mixed!
- 22. “ ■ The Collaboration Style is independent from the Communication Style This is very often mixed up!
- 23. The collaboration style is independent of communication style! Checkout Payment Inventory Shipment Order placed Payment received Retrieve Payment Order Fulfillment Asynchronous non-blocking Asynchronous non-blocking Synchronous blocking Choreography Orchestration
- 24. How could such a mix of orchestration and choreography look like? Orchestration Orchestration Choreography
- 25. “ 25 Communication Options - Summary 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
- 26. “ 26 Loosely or lousily coupled? 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
- 27. Summary and Take-Aways 27 ■ Know ■ communication styles (sync/async) ■ collaboration styles (command/event) ■ You can get rid of temporal coupling with asynchronous communication ■ Make sure you or your team can handle it ■ You will need long running capabilities (you might need it anyway) ■ Synchronous communication + correct patterns might also be OK ■ Domain coupling does not go away!
- 28. Thanks for listening! Thomas Heinrichs Developer Advocate @ Camunda Thomas.heinrichs@camunda.com @hafflgav GitHub Repository with an example: https://github.com/berndruecker/flowing-retail/tree/master/kafka