Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

GopherCon UK 2018 - Orchestration of microservices

496 views

Published on

Slides from my talk at GopherCon 2018 in London.

Published in: Technology

GopherCon UK 2018 - Orchestration of microservices

  1. 1. @berndruecker Orchestration of microservices
  2. 2. Some Service Some Service Some Service Some Service Some Service Some Service Some Service Microservices…
  3. 3. Some boring groundwork* * incomplete and inacurate, but useful Blocking Non-blocking sync async
  4. 4. What is a good place to be? Blocking sync async Non-blocking
  5. 5. Synchronous communication is the crystal meth of distributed programming Todd Montgomery and Martin Thompson in “How did we end up here” at GOTO Chicago 2015
  6. 6. What is a good place to be? Blocking sync async Non-blocking
  7. 7. There will be challenges anyway! Blocking sync async Non-blocking
  8. 8. Warning: Contains Opinion
  9. 9. Berlin, Germany bernd.ruecker@camunda.com @berndruecker Bernd Ruecker Co-founder and Developer Advocate of Camunda
  10. 10. Some communication challenges can be solved by state machines aka workflow engines.
  11. 11. We will do coding with Other tools availabe (e.g. Uber Cadence)
  12. 12. Photo by pxhere, available under Creative Commons CC0 1.0 license.
  13. 13. Challenge: communication problems
  14. 14. Distributed systems
  15. 15. Distributed systems
  16. 16. Distributed systems
  17. 17. Challenge: communication problems Credit Card Payment
  18. 18. Strategy: Ignore
  19. 19. Strategy: Ignore Frequency? Impact? Fix later?
  20. 20. Strategy: Rethrow error?
  21. 21. Challenge: communication problems Credit Card Payment Order
  22. 22. Some Service Some Service Some Service Some Service Some Service Some Service Some Service
  23. 23. Then you get this!
  24. 24. Some Service Some Service Some Service Some Service Some Service Some Service Some Service
  25. 25. Strategy: Retry Credit Card Payment
  26. 26. Requirement: Idempotency of services! Photo by pixabay, available under Creative Commons CC0 1.0 license.
  27. 27. Requirement: Idempotency of services! Photo by Chr.Späth, available under Public Domain.
  28. 28. Strategy: Retry Credit Card Payment Charge Credit Card cardNumber amount Charge Credit Card cardNumber Amount transactionId Not idempotent Idempotent
  29. 29. Distributed systems
  30. 30. Strategy: stateful retry Credit Card Payment
  31. 31. Persist thing (Entity, Document, Actor, …) State machine or workflow engine DIY = effort and accidental complexity Scheduling, Versioning, operating, visibility, scalability, … Handling State
  32. 32. Client Zeebe Zeebe Broker Your applicationModel defined here and executed here Workers subscribe (pub/sub) JVM Polyglott, e.g. Go, Java, C#, Node, …
  33. 33. Live hacking https://github.com/flowing/flowing-retail/tree/master/rest
  34. 34. Client Zeebe Zeebe Broker Your application Streaming / reactive Scale elastically and horizontally Event streaming Peer-to-peer cluster Single Writer Consensus via Raft Model defined here and executed here Workers subscribe
  35. 35. Workflow automation at scale! low latency, high-throughput low frequency, latency doesn‘t matter What people think workflow automation can do What we currently teach workflow automation to be able to do What workflow automation can already do today
  36. 36. Zeebes Role Blocking sync async Most often Zeebe is used from services Non-blocking
  37. 37. Zeebes Role Blocking Non-blocking sync async Some customers envision Zebe as work distribution
  38. 38. BPMN Business Process Model and Notation ISO Standard
  39. 39. BPMN Executable and mature Easy to understand* Widespread *(for Biz, Dev, and Ops)
  40. 40. Zeebe Status Working towards 1.0 end of the year
  41. 41. But back to concepts
  42. 42. Challenge: network errors Credit Card Payment
  43. 43. Payment Stateful retry Credit Card REST
  44. 44. What if stateful retry gives up? Credit Card Payment REST
  45. 45. It is impossible to differentiate certain failure scenarios. Independant of communication style! Service Provider Client
  46. 46. Stateful retry & cleanup Credit Card Payment REST
  47. 47. Know what‘s going on
  48. 48. Challenges around message correlation
  49. 49. Challenge: Timeout handling Credit Card Payment + Incident handling / alarming
  50. 50. Challenge: Timeout handling Credit Card Payment
  51. 51. Challenge: Correlation multiple messages
  52. 52. Challenge: Correlation multiple messages
  53. 53. Zeebe can buffer messages (if workflow not yet ready)
  54. 54. Sophisticated message correlation possibilities
  55. 55. Challenges around consistency
  56. 56. Customer example Service (e.g. Go) Kafka RDMS 1. 3. 2.
  57. 57. Customer example Service (e.g. Go) Kafka RDMS 1. 3. 2.
  58. 58. Customer example Service (e.g. Go) Kafka RDMS 1. 3. 2.
  59. 59. Similar when calling multiple services
  60. 60. Similar when calling multiple services
  61. 61. Orchestration
  62. 62. The microservice community favours an alternative approach: smart endpoints and dumb pipes. [… Microservices …] are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool. https://www.martinfowler.com/articles/microservices.html
  63. 63. Peer-to-peer communication Checkout Payment Inventory Shipment
  64. 64. Peer-to-peer communication Checkout Payment Inventory Shipment
  65. 65. 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
  66. 66. 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
  67. 67. 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
  68. 68. Microservice pioneers have become aware
  69. 69. Peer-to-peer communication Checkout Payment Inventory Shipment Fetch the goods before the payment
  70. 70. Peer-to-peer communication Checkout Payment Inventory Shipment Fetch the goods before the payment
  71. 71. Order Extract the end-to-end responsibility Checkout Payment Inventory Shipment
  72. 72. Order Checkout Payment Inventory Shipment
  73. 73. Order Checkout Payment Inventory Shipment
  74. 74. Order Checkout Payment Inventory Shipment Workflow engine itself can run decentralized or centralized
  75. 75. # Every way of remote communication has challenges # Some challenges require stateful components # Complex peer-to-peer communication can lead to problems, balance choreography and orchestration
  76. 76. Thank you!
  77. 77. bernd.ruecker@camunda.com @berndruecker https://bernd-ruecker.com https://blog.bernd-ruecker.com https://github.com/flowing https://www.infoq.com/articles/events- workflow-automation Contact: Slides: Blog: Code: https://www.infoworld.com/article/3254777/ application-development/ 3-common-pitfalls-of-microservices- integrationand-how-to-avoid-them.html https://thenewstack.io/5-workflow-automation- use-cases-you-might-not-have-considered/

×