Download as PDF, PPTX
![Disclaimer: I do not advertise microservices!
But assume you [want | have] to use microservices
– what to do then?](https://image.slidesharecdn.com/2017-05-09orchestrationofmicroservices-170509154334/75/JAX-2017-talk-Orchestration-of-microservices-7-2048.jpg)
Uploaded byBernd Ruecker
JAX 2017 talk: Orchestration of microservices
This document discusses orchestrating microservices using event-driven communication and process managers. It describes how microservices communicate asynchronously using events without direct knowledge of each other. Process managers listen for events, transform them into commands, and handle long-running workflows and state. This approach provides visibility into end-to-end processes while maintaining autonomy and decoupling between microservices. The document also cautions against over-engineering with complex BPM suites and recommends using lightweight, embeddable process engines.
More Related Content
Similar to JAX 2017 talk: Orchestration of microservices
JAX 2017 talk: Orchestration of microservices
- 1. Orchestration of Microservices bernd.ruecker@camunda.com Withthoughts from http://flowing.io @berndruecker | @martinschimak
- 2.
- 3.
- 4. Assume you want tobuild a Dash button
- 5. pay receive shipment place order I wantto have one item! I am happy!
- 6.
- 7. Disclaimer: I donot advertise microservices! But assume you [want | have] to use microservices – what to do then?
- 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. Event driven microservices MicroserviceMicroservice Microservice A B C
- 10. Communication via events MicroserviceMicroservice A C Event event name payload no receipient
- 11. Communication via Events MicroserviceMicroservice A C Event Does not know about C Does not know about A
- 12. It is notSOA and not about a central ESB. http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
- 13. It is notSOA Service Service A C ESB „smart endpoints and dumb pipes”
- 14. Value proposition: fightconway, keep agility and ease changes Microservice Microservice A C
- 15.
- 16.
- 17.
- 18. Business Capabilities Bounded Contexts = Microservices Order placed Shop PaymentShipping Business Outputs / Domain Events Inventory Payment received Goods fetched Goods shipped
- 19.
- 20. Let‘s zoom inthe payment context Payment Order placed Payment received
- 21. Let‘s zoom inthe payment context Payment Order placed Payment received The payment context has to listen to „order placed“ event
- 22. De-coupling? Payment Order placed Service fullfilled … Whenever a newclient 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. Event command transformation Payment Retrieve payment Order placedTransformation Command Something has to happen in the future 1 recipient Event Something has happend in the past 0..n recipients
- 24.
- 25. Event vs. command Payment Retrieve payment Order placedOrder decide where to do the coupling
- 26. Vaughn Vernon „Process Managers transformEvents into Commands“ At IDDD Workshop February 2017
- 28. Some things inlive might be slow Payment Retrieve payment Order placed Order Payment retrieved
- 29. Long running flows requirepersistent state
- 30. In microservice architectureseverything leaving the service boundary is potentially long running
- 31. Saga The classical Sagapattern 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
- 32.
- 34.
- 35. Process Manager • Doevent command transformation • Handle state for long running flows
- 36. Reactive actor withAkka https://github.com/VaughnVernon/ReactiveMessagingPatterns_ActorModel/blob/master/src /co/vaughnvernon/reactiveenterprise/processmanager/ProcessManager.scala#L91
- 37.
- 38.
- 39.
- 40. Logic remains innormal code
- 41. Tools provide persistentstate, visibility, … +
- 42. Process Manager • Doevent command transformation • Handle state for long running flows • Implement the flow as 1st class citizen of domain logic
- 43. Martin Fowler Event notificationis 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
- 44. It is aboutvisbility Payment Retrieve payment Order placed Order
- 45. It is aboutubiquitous language! Ubiquitous Language Software Experts Domain Experts
- 46. It is aboutchangability
- 47. New business requirements Order placed Payment received Goods fetched Goods shipped InventoryPaymentShippingShop VIP customers can order with invoice (and pay later)
- 48. New business requirements Order placed Payment received Goods fetched Goods shipped InventoryPaymentShippingShop VIP customers can order with invoice (and pay later) If VIP customer If not VIP customer Order billed Billing If VIP customer
- 49.
- 50. It helps youas a developer!
- 51. Error and timeouthandling
- 52.
- 53.
- 54. The power ofgraphics Graphics Code http://vasters.com/archive/Sagas.html
- 55.
- 56. The 7 sinsof workflow 3 2 4 6 5 7 1 http://blog.bernd-ruecker.com/
- 57. The 7 sinsof workflow Zero-code suites Homegrown engine No engine Wrong engine Wrong usage 4 6 5 7 http://blog.bernd-ruecker.com/
- 58. Death by propertiespanel Script: Please enter your complex code here. (Without IDE support of course!)
- 59. BPM Suites By theway, we introduce an own development approach, IDE, version control, user management, reporting, …
- 60. Zero code &developers We have a lot of problems! It totally sucks! I hate BPM!
- 61. Bernd Rücker Consultant &Evangelist > 10+ years workflow http://bernd-ruecker.com/ bernd.ruecker@camunda.com Co-founder Camunda http://camunda.org/
- 63. Define flows programaticallyor graphically
- 64. Define flows programaticallyor graphically Todo…
- 65. Productive development andtesting
- 66.
- 67. Do it yourself?Actor Entity Routing Slip © Picture from http://www.windtraveler.net/2010_06_01_archive.html
- 68. Think about subsequentrequirements Monitoring & Operations Visibility Versioning Time & Timeouts Domain Logic
- 69. The 7 sinsof 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
- 70.
- 71. You are notforced to violate the bounded context! Order Feedback Inventory Payment
- 72. Payment Local flows inthe bounded contexts Order
- 73. Lightweight and embeddableengine 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
- 74. Slides are nice– but what about code? Sure: http://github.com/flowing/
- 75. Demo architecture InventoryPaymentOrder Shipping H2 ShopMonitor Camunda Webapp on Tomcat for demo in single Java VM for simplicity http://flowing.io/
- 77. Code online: https://github.com/flowing Slides online: http://bernd-ruecker.com Feedback: http://bernd-ruecker.com/feedback Withthoughts from http://flowing.io @berndruecker | @martinschimak
- 78.