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.

JFS 2017 - Orchestration of microservices

729 views

Published on

Slides from my talk at Java Forum Stuttgart on 6th of June 2017.

Published in: Technology
  • Nice presentation! About our last conversation, when i heard he turned $10 into $10,000 in 2 months, i could not believe it was possible. I thought it might be a bug, but word on the street is that it's real. If it is, then we might be in for a real treat! I'll stay on the case and let you know more as soon as I speak with the developers, anyway i will go for it since they have a 60 day money back guarantee, so if not quiet like Jordan told me i will ask for a refund. In the meanwhile, check out the video i told you about last week: http://bit.ly/secretvideopage
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

JFS 2017 - Orchestration of microservices

  1. 1. Orchestration of Microservices bernd.ruecker@camunda.com With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. 2. AT&T
  3. 3. Microservoices?
  4. 4. https://www.flickr.com/photos/12567713@N00/310639290
  5. 5. 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
  6. 6. Increasing complexity of relation- ships
  7. 7. Event-Driven Microservices Microservice Microservice A B Event event name payload no receipient
  8. 8. Event-Driven Microservices Microservice Microservice A B Event Does not know about B Does not know about A
  9. 9. Isn‘t that SOA? Service Service A B ESB
  10. 10. It is not SOA Service Service A B ESB „smart endpoints and dumb pipes”
  11. 11. Disclaimer: I do not advertise event-driven microservices as silver bullet! Only use it when appropriate. Handle with care!
  12. 12. Distributed systems
  13. 13. You need some safe harbors and strategies to sail the wild ocean
  14. 14. Microservices Event Driven & Reactive Domain Driven Design
  15. 15. Let‘s do an example! Assume you want to build a Dash button.
  16. 16. pay receive shipment place order I want to have one item! I am happy!
  17. 17. Business Capabilities Bounded Contexts = Microservices Order placed Shop Payment Shipping Business Outputs / Domain Events Inventory Payment received Goods fetched Goods shipped
  18. 18. Collaboration using an eventflow Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop
  19. 19. Great!
  20. 20. Great?
  21. 21. Let‘s zoom in the payment context Payment Order placed Payment received
  22. 22. Let‘s zoom in the payment context Payment Order placed Payment received The payment context has to listen to „order placed“ event
  23. 23. 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
  24. 24. 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
  25. 25. Order context Payment Retrieve payment Order placed Order
  26. 26. Event vs. command Payment Retrieve payment Order placed Order decide where to do the coupling
  27. 27. Business Capabilities Order placed Shop Payment ShippingInventory Payment received Goods fetched Goods shipped Order Order completed Retrieve payment Fetch goods Ship goods
  28. 28. Quality Criteria: Changability VIP customers can order with invoice (and pay later)
  29. 29. Changability with pure event-chain Order placed Payment received Goods fetched Goods shipped InventoryPayment ShippingShop If VIP customer If not VIP customer Order billed Billing If VIP customer VIP customers can order with invoice (and pay later)
  30. 30. Changability with Event Command Transformation Order placed Shop Payment ShippingInventory Payment received Goods fetched Goods shipped Order Order completed VIP customers can order with invoice (and pay later) Change how to issue commands
  31. 31. Quick demo http://github.com/flowing/
  32. 32. Now back to real-life
  33. 33. Some things in live might be slow Payment Retrieve payment Order placed Order Payment retrieved
  34. 34. Long running flows require persistent state
  35. 35. How to implement?
  36. 36. State in entity More alternatvies in my blog: https://blog.bernd-ruecker.com/ how-to-implement-long-running-flows-sagas-business-processes-or-similar-3c870a1b95a8
  37. 37. The 7 sins of workflow 3 2 4 6 5 7 1 http://blog.bernd-ruecker.com/
  38. 38. The 7 sins of workflow 3 4 6 5 7 http://blog.bernd-ruecker.com/ No state machine Homegrown state machine
  39. 39. Think about subsequent requirements Monitoring & Operations Visibility Versioning Time & Timeouts Domain Language Performance & Scaling
  40. 40. Process Manager • Do event command transformation • Handle state for long running flows
  41. 41. State machine http://camunda.org/
  42. 42. Logic remains in normal code
  43. 43. Tools provide persistent state, visibility and much more +
  44. 44. On top: visbility Payment Retrieve payment Order placed Order
  45. 45. 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
  46. 46. Smells like „BPM“?
  47. 47. The 7 sins of workflow Homegrown engine BPM monolith No engine Wrong engine Wrong usage http://blog.bernd-ruecker.com/ 4 5 7 3
  48. 48. The end-to-end process?
  49. 49. Don‘t do a „BPM monolith“ when using Microservices! Order Feedback Inventory Payment
  50. 50. Payment Local flows in the bounded contexts Order
  51. 51. Multiple engines Payment Order engine engine … Inventory Shipping … engine
  52. 52. The 7 sins of workflow Zero-code suites Homegrown engine No engine Wrong engine Wrong usage 4 5 7 http://blog.bernd-ruecker.com/ BPM monolith
  53. 53. Death by properties panel Script: Please enter your complex code here. (Without IDE support of course!)
  54. 54. Bernd Rücker Consultant & Evangelist 10+ years workflow http://bernd-ruecker.com/ bernd.ruecker@camunda.com Co-founder Camunda http://camunda.org/
  55. 55. Define flows programatically or graphically
  56. 56. Productive development and testing
  57. 57. Developer friendly
  58. 58. Big challenges for developers ahead!
  59. 59. Error and timeout handling
  60. 60. Handling complex scenarios
  61. 61. Demo http://github.com/flowing/
  62. 62. Demo architecture InventoryPaymentOrder Shipping H2 Shop Monitor Camunda Webapp on Tomcat for demo in single Java VM for simplicity https://github.com/flowing/flowing-retail/
  63. 63. Lightweight state machines or workflow engines are not evil! They do help you solving some really hard coding problems. These problems become more and more frequent every day.
  64. 64. https://www.infoq.com/articles/microservice-event-choreographies
  65. 65. 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
  66. 66. Thank you!

×