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.

JAX 2017 talk: Orchestration of microservices

1,702 views

Published on

Slides from my talk at JAX conference in Mainz on 9th of May 2015. Code examples are available online: https://github.com/flowing.

Published in: Technology
  • Be the first to comment

JAX 2017 talk: Orchestration of microservices

  1. 1. Orchestration of Microservices bernd.ruecker@camunda.com With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. 2. Orchestration? Microservices?
  3. 3. AT&T
  4. 4. Assume you want to build a Dash button
  5. 5. pay receive shipment place order I want to have one item! I am happy!
  6. 6. How to build?
  7. 7. Disclaimer: I do not advertise microservices! But assume you [want | have] to use microservices – what to do then?
  8. 8. Microservices • Independent components • Independent deployments • Decoupling between components • Dedicated teams to fight conways law • Autonomy of technology decisions • Avoid horizontal team boundaries • New DevOps paradigms Microservice Microservice Microservice Monolith A B C A B C
  9. 9. Event driven microservices Microservice Microservice Microservice A B C
  10. 10. Communication via events Microservice Microservice A C Event event name payload no receipient
  11. 11. Communication via Events Microservice Microservice A C Event Does not know about C Does not know about A
  12. 12. It is not SOA and not about a central ESB. http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
  13. 13. It is not SOA Service Service A C ESB „smart endpoints and dumb pipes”
  14. 14. Value proposition: fight conway, keep agility and ease changes Microservice Microservice A C
  15. 15. Conways Law Organisation Software System
  16. 16. https://www.flickr.com/photos/12567713@N00/310639290
  17. 17. Yeah.
  18. 18. Business Capabilities Bounded Contexts = Microservices Order placed Shop Payment Shipping Business Outputs / Domain Events Inventory Payment received Goods fetched Goods shipped
  19. 19. Eventflow Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop
  20. 20. Let‘s zoom in the payment context Payment Order placed Payment received
  21. 21. Let‘s zoom in the payment context Payment Order placed Payment received The payment context has to listen to „order placed“ event
  22. 22. De-coupling? Payment Order placed Service fullfilled … Whenever a new client requires payment, the payment context has to be touched The payment context has to know all possible events that trigger a payment Subscription confirmed
  23. 23. Event command transformation Payment Retrieve payment Order placed Transformation Command Something has to happen in the future 1 recipient Event Something has happend in the past 0..n recipients
  24. 24. Order context Payment Retrieve payment Order placed Order
  25. 25. Event vs. command Payment Retrieve payment Order placed Order decide where to do the coupling
  26. 26. Vaughn Vernon „Process Managers transform Events into Commands“ At IDDD Workshop February 2017
  27. 27. Some things in live might be slow Payment Retrieve payment Order placed Order Payment retrieved
  28. 28. Long running flows require persistent state
  29. 29. In microservice architectures everything leaving the service boundary is potentially long running
  30. 30. Saga The classical Saga pattern example book hotel book car book flight cancel hotel cancel car 1. 2. 3. 5.6. 4. In case of failure trigger compensations book trip
  31. 31. How to implement?
  32. 32. Process Manager
  33. 33. Process Manager • Do event command transformation • Handle state for long running flows
  34. 34. Reactive actor with Akka https://github.com/VaughnVernon/ReactiveMessagingPatterns_ActorModel/blob/master/src /co/vaughnvernon/reactiveenterprise/processmanager/ProcessManager.scala#L91
  35. 35. State in entity
  36. 36. Routing slip http://vasters.com/archive/Sagas.html
  37. 37. State machine http://camunda.org/
  38. 38. Logic remains in normal code
  39. 39. Tools provide persistent state, visibility, … +
  40. 40. Process Manager • Do event command transformation • Handle state for long running flows • Implement the flow as 1st class citizen of domain logic
  41. 41. Martin Fowler Event notification is nice because it implies a low level of coupling, and is pretty simple to set up. It can become problematic, however, if there really is a logical flow that runs over various event notifications. The problem is that it can be hard to see such a flow as it's not explicit in any program text. Often the only way to figure out this flow is from monitoring a live system. This can make it hard to debug and modify such a flow. 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
  42. 42. It is about visbility Payment Retrieve payment Order placed Order
  43. 43. It is about ubiquitous language! Ubiquitous Language Software Experts Domain Experts
  44. 44. It is about changability
  45. 45. New business requirements Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop VIP customers can order with invoice (and pay later)
  46. 46. New business requirements Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop VIP customers can order with invoice (and pay later) If VIP customer If not VIP customer Order billed Billing If VIP customer
  47. 47. Adjusted flow
  48. 48. It helps you as a developer!
  49. 49. Error and timeout handling
  50. 50. Handling complex scenarios
  51. 51. Compensation
  52. 52. The power of graphics Graphics Code http://vasters.com/archive/Sagas.html
  53. 53. Smells like „BPM“?
  54. 54. The 7 sins of workflow 3 2 4 6 5 7 1 http://blog.bernd-ruecker.com/
  55. 55. The 7 sins of workflow Zero-code suites Homegrown engine No engine Wrong engine Wrong usage 4 6 5 7 http://blog.bernd-ruecker.com/
  56. 56. Death by properties panel Script: Please enter your complex code here. (Without IDE support of course!)
  57. 57. BPM Suites By the way, we introduce an own development approach, IDE, version control, user management, reporting, …
  58. 58. Zero code & developers We have a lot of problems! It totally sucks! I hate BPM!
  59. 59. Bernd Rücker Consultant & Evangelist > 10+ years workflow http://bernd-ruecker.com/ bernd.ruecker@camunda.com Co-founder Camunda http://camunda.org/
  60. 60. Define flows programatically or graphically
  61. 61. Define flows programatically or graphically Todo…
  62. 62. Productive development and testing
  63. 63. Developer friendly
  64. 64. Do it yourself? Actor Entity Routing Slip © Picture from http://www.windtraveler.net/2010_06_01_archive.html
  65. 65. Think about subsequent requirements Monitoring & Operations Visibility Versioning Time & Timeouts Domain Logic
  66. 66. The 7 sins of workflow Zero-code suites Homegrown engine Granularity bloopers BPM monolith Stakeholders habitat violation Over engineering No engine Wrong engine Wrong usage http://blog.bernd-ruecker.com/ 4 5 7
  67. 67. The end-to-end process?
  68. 68. You are not forced to violate the bounded context! Order Feedback Inventory Payment
  69. 69. Payment Local flows in the bounded contexts Order
  70. 70. Lightweight and embeddable engine Engine must be • easy to use • developer friendly also in the scope of multiple scopes/aggregates/services • technically • license model Payment Order engine engine … Inventory Shipping … engine
  71. 71. Slides are nice – but what about code? Sure: http://github.com/flowing/
  72. 72. Demo architecture InventoryPaymentOrder Shipping H2 Shop Monitor Camunda Webapp on Tomcat for demo in single Java VM for simplicity http://flowing.io/
  73. 73. Code online: https://github.com/flowing Slides online: http://bernd-ruecker.com Feedback: http://bernd-ruecker.com/feedback With thoughts from http://flowing.io @berndruecker | @martinschimak
  74. 74. Thank you!

×