Download as PDF, PPTX
Uploaded byBernd Ruecker
3 common pitfalls in microservice integration
The document discusses 3 common pitfalls in microservice integration: 1. Asynchronicity - asynchronous communication introduces complexity in monitoring timeouts. 2. Distributed transactions - distributed transactions are challenging due to the possibility of temporarily inconsistent states. Compensation patterns can help address this. 3. Communication complexity - communication between services is complex due to failures, retries, and idempotency requirements. It recommends using workflow engines to help address these pitfalls by enabling stateful retries, timeouts, compensation, and keeping failures local. This provides better resilience compared to traditional messaging approaches.
More Related Content
Similar to 3 common pitfalls in microservice integration
3 common pitfalls in microservice integration
- 1. 3 Common Pitfallsin Microservice Integration and How to Avoid Them @berndruecker
- 2. Berlin, Germany bernd.ruecker@camunda.com @berndruecker Bernd Ruecker Co-founderand Developer Advocate of Camunda
- 3. REST, SOAP, Cloud, Saas, Microservices,SCS, FaaS, Serverless, …
- 4.
- 5.
- 6.
- 7. Some Service Some Service Some Service Some Service Some Service Some Service Some Service Failure will happen. Acceptit! But keep it local! Be resilient.
- 8. Let‘s start witha simple example Credit Card Payment REST
- 9.
- 10. Circuit Breaker Photo by CITYEDV,available under Creative Commons CC0 1.0 license.
- 11.
- 12. Fail fast is important butnot enough!
- 13. Photo by Tookapic,available under Creative Commons CC0 1.0 license.
- 14. „There was anerror while sending your boarding pass“
- 15.
- 16.
- 17.
- 18.
- 20.
- 21.
- 22. Check-in Barcode Generator Web-UI Me Output Mgmt Current situation –the bad part Stateful Retry
- 24. We are havingsome technical difficulties and cannot present you your boarding pass right away. But we do actively retry ourselves, so lean back, relax and we will send it on time.
- 25.
- 26. Check-in Barcode Generator Web-UI Me Output Mgmt Possible situation –much better! Stateful Retry
- 27. Check-in Barcode Generator Web-UI Me Output Mgmt Stateful Retry Possible situation –much better! The failure never leaves this scope!
- 28. Persist thing (Entity, Document,Actor, …) State machine or workflow engine Typical concerns DIY = effort, accidental complexity Complex, proprietary, heavyweight, slow, don‘t scale, developer adverse Scheduling, Versioning, operating, visibility, scalability, … Handling State
- 29. Workflow engines, state machines Itis relevant in modern architectures
- 30. CADENCE Silicon valley has recognized Workflowengines, state machines
- 31.
- 32. CADENCE also at scale Workflowengines, state machines
- 33. CADENCE for todays demo Workflowengines, state machines
- 34.
- 35. Payment Now you havea state machine! Credit Card REST
- 36. has to implement Retry hasto implement Idempotency Client Service Provider
- 37. We are processingyour payment. Do not leave this page. And for god sake – do not reload! It is a business problem anyway!
- 38. We are processingyour payment. Do not leave this page. And for god sake – do not reload! It is a business problem anyway! We are currently processing your request. Don‘t worry, it will happen safely – even if you loose connection. Feel free to reload this page any time!
- 39. Distributed systems introducecomplexity you have to tackle! Credit Card Payment REST
- 40.
- 41. It is impossibleto differentiate certain failure scenarios. Independant of communication style! Service Provider Client
- 42. Distributed systems introducecomplexity you have to tackle! Credit Card Payment REST
- 43. Distributed systems introducecomplexity you have to tackle! Credit Card Payment REST
- 44. BPMN Business Process Model andNotation ISO Standard
- 45. BPMN Executable and mature Easyto understand* Widespread *(for Biz, Dev, and Ops)
- 46.
- 47. Compare to e.g.Step Functions
- 48. Workflows live within serviceboundaries Credit Card Payment REST
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55. generateBoardingPass HTTP 200 OK HTTP202 ACCEPTED Check-in A synchronous response is possible in the happy case, otherwise it is switched to asynchronous processing.
- 56. „The customer wantsa synchronous response“ Check-in Barcode Generator Web-UI Me Output Mgmt „Eh – no!“
- 57. Synchronous communication is thecrystal meth of distributed programming Todd Montgomery and Martin Thompson in “How did we end up here” at GOTO Chicago 2015
- 58.
- 59.
- 60.
- 61.
- 62.
- 63. has to implement Timeout,Retry has to implement Idempotency Client Service Provider
- 64. Who uses amessage bus?
- 65. Who has noproblems operating a message bus? Dead messages | No context | Inaccesible payload | Hard to redeliver | Home-grown message hospitals | …
- 66.
- 67.
- 68.
- 69.
- 70.
- 71. Distributed transactions usingcompensation * Compensation
- 72. Eventual consistency Temporarily inconsistent state Butonly temporarily!
- 73.
- 74. has to implement Timeout,Retry, Compensation has to offer Compensation has to implement Idempotency Client Service Provider
- 75. has to implement Timeout,Retry, Compensation has to offer Compensation has to implement Idempotency Client Service ProviderDon‘t forget about state
- 76. Before mapping processes explicitlywith BPMN, the truth was buried in the code and nobody knew what was going on. Jimmy Floyd, 24 Hour Fitnesse „
- 77. Event-driven example alsoavailable InventoryPaymentOrder ShippingCheckout Monitor https://github.com/flowing/flowing-retail/ Human Tasks H2 H2
- 78. Workflows live insideservice boundaries
- 80. Sales-Order & Order-Fulfillment viaCamunda for every order worldwide (Q2 2017: 22,2 Mio)
- 81. # Be awareof complexity of distributed systems # Know strategies and tools to handle it e.g. Circuit breaker (Hystrix) Workflow engine for stateful retry, waiting, timeout and compensation (Camunda)
- 82.
- 83.