JCon 2021 - Loosely or lousily coupled
•
0 likes•390 views
This document discusses communication patterns in microservices architectures. It compares synchronous vs asynchronous communication and how they impact coupling between services. It defines different types of coupling, such as implementation, temporal, deployment, and domain coupling, and provides recommendations for how to reduce or manage each type of coupling. Remote communication patterns like circuit breakers, retries, and sagas are presented for surviving communication failures between loosely coupled services.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to JCon 2021 - Loosely or lousily coupled
Similar to JCon 2021 - Loosely or lousily coupled (20)
More from Bernd Ruecker
More from Bernd Ruecker (14)
Recently uploaded
Recently uploaded (20)
JCon 2021 - Loosely or lousily coupled
- 1. Loosely or Lousily Coupled? Understanding Communication Patterns in Microservices Architectures @berndruecker
- 2. Let‘s talk about food
- 3. How does ordering Pizza work? Pizza Place You Phone Call Synchronous blocking communication Feedback loop (ack, confirmation or rejection) Temporal coupling (e.g. busy, not answering) Pizza Place You Email Asynchronous non-blocking communication No temporal coupling Pizza Place You A feedback loop might make sense (ack, confirmation or rejection) Email Confirmation Email
- 4. Feedback loop != result Pizza Place You Email Confirmation Email Pizza Delivery Feedback (ACK, confirmation, rejection) Result
- 5. Synchronous blocking behavior for the result? Bad user experience Does not scale well
- 6. Scalable Coffee Making https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html Photo by John Ingle @berndruecker
- 7. Scalable Pizza making La Pizza Cresci Cannes https://www.maison-cresci.com/ from http://www.travellingsnail.com/content/la-pizza-cresci-cannes
- 8. PUT/order Synchronous results? Pizza Place You Pizza Delivery HTTP 200 The task of Pizza making is long running
- 9. Only the first communication step is synchronous Pizza Place You PUT/order HTTP 200 Pizza Delivery The task of Pizza making is long running
- 10. bernd.ruecker@camunda.com @berndruecker http://berndruecker.io/ Bernd Ruecker Co-founder and Chief Technologist of Camunda
- 11. Making Pizza is long running
- 12. A workflow engine provides long running capabilities Workflow Engine Scheduler Durable State Workflow Definitions V1 V2 Workflow Engine: Is stateful Can wait Can retry Can escalate Can compensate Provides visibility
- 13. Execute Processes 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 RESTendpoint Instance Id Process Definition Current State … …-7454 payment „Charge Credit Card“ … …-4571 payment „Charge Credit Card“ … Process Instance Table Durable state of workflow engine (e.g. via relational database) Your glue code to implement the RESTcall @Task('chargeCreditCard') chargeCreditCard() { ... restClient.put( 'http://creditCards/charge/', requestData) } Credit Card Service REST
- 14. Value Proposition of a Workflow Engine Value of Visibility Value of long running capabilities Process Orchestration Business Transactions, Sagas Solving challenges with remote communication Integration Patterns Graphical Programming Effort of introducing a workflow engine
- 15. This is orchestration – right?
- 16. Command vs. event-based communication Pizza Place You I order this pizza OK – got it Command = Intent Cannot be ignored Independant of communication channel Pizza Place You „Hey – I am hungry!“ Event = Fact Sender can't control what happens
- 17. Events vs. Commands „Pizza Salmon is ready!“ I baked this pizza for Andrea. Please package it immediately and deliver it while it‘s hot!
- 18. 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.
- 19. Choreography Hey – somebody ordered Hey – Pizza is ready
- 21. Definition Orchestration = command-driven communication Choreography = event-driven communication
- 22. Let‘s switch examples: Order fulfillment Checkout Payment Inventory Shipment Order placed Payment received Goods shipped Goods fetched @berndruecker
- 24. Phil Calcado at QCon NYC 2019
- 25. Order Fulfillment Orchestration and Choreography Checkout Payment Inventory Shipment Payment received Order placed Retrieve payment @berndruecker This is choreography This is orchestration
- 26. Order Fulfillment Collaboration style is independant of communication style Checkout Payment Inventory Shipment Payment received Order placed Retrieve payment @berndruecker Choreography Orchestration Asynchronous non-blocking Asynchronous non-blocking Synchronous blocking
- 28. Sam Newman: Building Microservices @berndruecker
- 29. Mix orchestration and choreography Orchestration Orchestration Orchestration Choreography @berndruecker
- 30. Want to learn more about choreography vs. orchestration? https://learning.oreilly.com/library/view/practical-process-automation/9781492061441/ 30 days trial: https://learning.oreilly.com/get-learning/?code=PPAER20 Recording from QCon: https://drive.google.com/file/d/1IRWoQCX-gTPs7RVP5VrXaF1JozYWVbJv/view?usp=sharing Slides: https://www.slideshare.net/BerndRuecker/gotopia-2020-balancing-choreography-and-orchestration
- 31. Communication Options – Quick 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 This is not the same!
- 32. Coupling
- 33. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid
- 34. Types of Coupling Type of coupling Description Example Recommendation Implementation Coupling Service knows internals of other services Joined database Avoid
- 35. 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
- 36. 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
- 37. 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
- 38. 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
- 39. 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
- 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 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 This is influenced with the communication or collaboration style
- 42. Messaging?
- 43. Patterns To Survive Remote Communication Service Consumer Pattern/Concept Use With Service Provider X Service Discovery Sync (X) X Circuit Breaker Sync X Bulkhead Sync (X) Load Balancing Sync X X Retry Sync / Async X Idempotency Sync / Async X De-duplication Async X (X) Back Pressure & Rate Limiting Sync / (Async) X X Await feedback Async X Sagas Sync / Async (X) …
- 44. Circuit Breaker Photo by CITYEDV, available under Creative Commons CC0 1.0 license.
- 45. Circuit Breaker Webshop You PUT/order Address Check Payment from https://martinfowler.com/bliki/CircuitBreaker.html
- 46. Circuit Breaker Webshop You PUT/order Address Check Payment @CircuitBreaker(name = BACKEND, fallbackMethod = "fallback") public boolean addressValid(Address a) { return httpEndpoint.GET(...); } private boolean fallback(Address a) { return true; } e.g. Resilience4J: resilience4j.circuitbreaker: instances: BACKEND: registerHealthIndicator: true slidingWindowSize: 100 permittedNumberOfCallsInHalfOpenState: 3 minimumNumberOfCalls: 20 waitDurationInOpenState: 50s failureRateThreshold: 50
- 48. Stateful retry Webshop You PUT/order Address Check Payment Workflow Engine Scheduler Durable State
- 49. 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
- 50. Summary so far… • 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!
- 51. Want to learn more… https://ProcessAutomationBook.com/ Free electronic version available Featuring code examples: