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.

Goto meetup Stockholm - Let your microservices flow

476 views

Published on

Slides from my talk at the GOTO meetup in Stockholm on 5th of April 2017. The talk is about the flow in microservices, so how a bunch of loosely coupled microservices can fulfill an overall business goal.

Published in: Technology
  • Be the first to comment

Goto meetup Stockholm - Let your microservices flow

  1. 1. Let your microservices flow! bernd.ruecker@camunda.com With thoughts from http://flowing.io @berndruecker | @martinschimak
  2. 2. Assume you want to build a better Amazon Dash button
  3. 3. pay receive shipment place order I want to have one! I am happy!
  4. 4. How to build?
  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. Event driven microservices Microservice Microservice Microservice A B C Eventbus
  7. 7. Communication via events Microservice Microservice A C Eventbus Event event name payload no receipient
  8. 8. Communication via Events Microservice Microservice A C Eventbus Event Does not know about C Does not know about A
  9. 9. It is not SOA Service Service A C ESB „smart endpoints and dumb pipes”
  10. 10. Value proposition: fight conway, keep agility and ease changes Microservice Microservice A C Eventbus
  11. 11. Yeah.
  12. 12. So let‘s build that…
  13. 13. Sample microservices Inventory service Handles Stock, Reserviations and physical handling of goods Payment service Handles Payment Shipping service Manage shipments & labels for logistic providers
  14. 14. Eventflow Order Placed Payment Received Goods Picked Goods Shipped InventoryPayment ShippingShop
  15. 15. Implementation
  16. 16. Let‘s zoom in the payment service Payment service order placed payment received
  17. 17. Let‘s zoom in the payment service Payment service order placed payment received The payment service has to listen to „order placed“ event
  18. 18. De-coupling? Payment service order placed service fullfilled … Whenever a new service requires payment, the payment has to be changed Payment has to know all possible events that trigger a payment subscription confirmed
  19. 19. New business requirements Order Placed Payment Received Goods Picked Goods Shipped InventoryPayment ShippingShop VIP customers can order with invoice (and pay later)
  20. 20. New business requirements Order Placed Payment Received Goods Picked 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
  21. 21. Event Command Transformation Payment Service do payment order placed Transformation Command Something has to happen in the future 1 recipient Event Something has happend in the past 0..n recipients
  22. 22. This calls for an order service Payment service do payment order placed Order service
  23. 23. Microservices Inventory service Payment service Order service Does event command transformation for orders Shipping service
  24. 24. Shipment Service Inventory Service Payment Service Event Command Transformation do payment order placed Order Service payment received pick goods goods picked ship goods goods shipped order delivered Order Service Order Service Order Service
  25. 25. Smeels like a central ESB? http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
  26. 26. No! Far from it! Inventory service Payment service Order service Not in the pipe but in a domain related service. Probably simple code. Shipping service
  27. 27. Easiest implementation if (event.equals("order placed")) { issueCommand("do payment"); }
  28. 28. Implementation (with event command transformation)
  29. 29. But…
  30. 30. The example process receive shipment place order manual approval in case of risky orders risk check payment delivery
  31. 31. Requirements receive shipment place order manual approval in case of risky orders risk check payment delivery Long running, requires state handling Service collaboration, potentially long running
  32. 32. Long running flows have state
  33. 33. State in entity
  34. 34. Or a seperate state entity
  35. 35. State machine, e.g. Camunda http://camunda.org/
  36. 36. State machine, e.g. Camunda http://camunda.org/
  37. 37. Tools provide persistent state, visibility and more
  38. 38. The 7 sins of workflow and Java No engine Wrong engine 3 4 6 5 7 http://blog.bernd-ruecker.com/ 2
  39. 39. The 7 sins of workflow and Java Homegrown engine No engine Wrong engine 3 4 6 5 7 http://blog.bernd-ruecker.com/
  40. 40. The homegrown engine ©kallejipp/photocase.com Own DSL, parsing, graphical representation, modeler, persistence, escalation, version management, tooling, … Whole teams maintaining something that always lacks behind
  41. 41. Netflix also recognized
  42. 42. Camunda uses BPMN Worldwide adopted industry standard
  43. 43. Smells like „BPM“?
  44. 44. The 7 sins of workflow and Java Zero-code suites Homegrown engine No engine Wrong engine Wrong usage 4 6 5 7 http://blog.bernd-ruecker.com/
  45. 45. Death by properties panel Script: Please enter your complex code here. (Without IDE support of course!)
  46. 46. BPM Suites By the way, we introduce an own development approach, IDE, version control, user management, reporting, …
  47. 47. Zero code & developers We have a lot of problems! It totally sucks! I hate BPM!
  48. 48. Bernd Rücker Co-founder Camunda Consultant & Evangelist > 10+ years workflow http://bernd-ruecker.com/ bernd.ruecker@camunda.com Camunda Open source vendor Berlin & San Francisco > 60 employees www.camunda.org
  49. 49. Define flows programatically or graphically Todo…
  50. 50. Productive development and testing
  51. 51. Developer friendly
  52. 52. 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
  53. 53. You are not forced to violate the microservice ownership! Order Feedback Inventory Payment
  54. 54. Payment Overall choreography with local flows Order Eventbus
  55. 55. Lightweight and embeddable engines Engine must be • easy to use • developer friendly also in the scope of multiple scopes/aggregates/services • technically • license model Payment Order engine engine … … … … engine
  56. 56. It is about visibility!
  57. 57. It is about ubiquitos language!
  58. 58. Models are running code!
  59. 59. 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
  60. 60. Live Demo
  61. 61. Demo architecture InventoryPaymentOrder Shipping H2 Shop Monitor Camunda Webapp on Tomcat for demo in single Java VM for simplicity
  62. 62. Screenshots
  63. 63. Screenshots
  64. 64. We want to reserve goods even before we received the payment.
  65. 65. Adjust the flow
  66. 66. Changes Inventory service Payment service Order service Shipping service must provide reservation servicereserve goods at right moment Listen to goods reserved instead of order created. Listen to order created. With event command transformation Without
  67. 67. VIP customers can order with invoice (and pay later)
  68. 68. Adjusted flow
  69. 69. Required changes Inventory service Payment service Order service Shipping service Invoice service skip payment, but add open invoice Listen to order created VIP or payment received (non VIP). Listen to order created (VIP).
  70. 70. When a customer cancels, we want to win him back!
  71. 71. Required changes Inventory service Payment service Order service Shipping service Listen to appropriate events, no change anywhere else Winback service
  72. 72. We need more advanced stuff – can your flows do this?
  73. 73. Timeouts …after two weeks pricing is not binding any more
  74. 74. Compensation …in case of errors in error handling pay the money back to the customer
  75. 75. Summary • Microservices and event driven architecture go well together • You need an event command transformation • If the translation is stateful, consider using an appropriate engine • Modern lightweight engines foster and not hinder these architectures
  76. 76. Is it really for me? Isn‘t all of that just for FANG?
  77. 77. 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
  78. 78. Thank you! Any questions?
  79. 79. Coding exercise
  80. 80. Idea
  81. 81. Sorry for any bugs!
  82. 82. Participant Participant The setup Cloud Foundry Java application H2 Participant H2 REST
  83. 83. Participant Participant Cloud Foundry Java application H2 Participant REST The setup
  84. 84. Participant Participant The setup Cloud Foundry Java application H2 Participant H2 REST
  85. 85. Lab: https://github.com/berndruecker/camunda-interactive-lab CF Endpoint: https://camunda-interactive-lab.cfapps.io/ You can test the endpoint by e.g. checking for running instances: https://camunda-interactive-lab.cfapps.io/rest/engine/default/process-instance

×