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.

Watch your communication

1,283 views

Published on

In this talk, I address two topics.

The first topic is the "one size fits all" dogma that we see quite often in IT. I try to explain, why we do it but also what the pitfalls are and how oversimplified solution spaces lead to the same kind of accidental complexity when trying to solve a given business problem as overly complex solution spaces.

The second and core topic is the influence that a communication paradigm you use has on your functional design. Based on the observation that synchronous request/response in all its flavors is the usually used "one size fits all" communication paradigm, I use a real-life example to demonstrate how two different communication paradigms (synchronous request/response and asynchronous event-based communication) can lead to very different functional service designs - and that synchronous request/response not necessarily leads to the more appropriate functional design.

The bottom line of the talk is that you should not give up your design options prematurely in order to be able to find the best problem-solution fit and that the choice of the communication paradigm is a more important options than most people usually think it is.

As always the voice track is missing and therefore quite a bit of the information (or probably most of the information) contained in the talk. But hopefully the slides still give you some useful pointers.

Published in: Technology
  • Be the first to comment

Watch your communication

  1. 1. Watch your communication How communication drives design Uwe Friedrichsen – codecentric AG – 2016
  2. 2. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com
  3. 3. The “one-size-fits-all” trap
  4. 4. Standardization as a virtue
  5. 5. We see that a lot •  One programming language •  One framework •  One build system •  One type of runtime unit •  One data store •  One type of database access •  One application server •  One ... •  One communication paradigm
  6. 6. Why are we doing it?
  7. 7. Reducing complexity •  Avoid intellectual overload •  Easier to understand •  Easier to change •  Faster to change •  Easier to operate •  Less error-prone •  Cheaper
  8. 8. These are valid and important reasons …
  9. 9. ... but that is just one side of the coin
  10. 10. The complexity of a solution
 must match
 the complexity of the problem to solve
  11. 11. If your task is to build a box from pre-cut boards,
 only using a hammer might be adequate
  12. 12. If your task is also to paint the box you just built,
 only having a hammer might be a problem …
  13. 13. Now imagine building a whole house
 just with a hammer …
  14. 14. Yet, in IT we often tend to build whole houses
 just with a hammer because boxes can be built with a hammer
  15. 15. Complexity mismatch means •  Increased accidental complexity •  Harder to understand •  Harder to change •  Slower to change •  Harder to operate •  More error-prone •  More expensive
  16. 16. Complexity Essential complexity Adds direct accidental complexity Problem complexity Ideal solution complexity Adds indirect accidental complexity
  17. 17. Complexity Problem complexity Overly complex solution Increased accidental complexity More “tooling” than needed to get the job done well
  18. 18. Complexity Problem complexity Over- simplified solution Increased accidental complexity Not enough “tooling” to get the job done well
  19. 19. Overall Solution Complexity := Essential Problem Complexity + Solution Complexity Mismatch Solution Complexity Mismatch a.k.a. Accidental Complexity Be aware that mismatch in both directions
 adds to overall solution complexity
  20. 20. Complexity Essential complexity Problem complexity Aim for the least complex solution
 with respect to the problem you have to solve (Yes, it is about trade-offs – as always in architecture)
  21. 21. Communication paradigms
  22. 22. Communication paradigms •  Dimensions of communication •  Synchronous vs. asynchronous •  Request/response vs. message passing •  Commands, Events and Documents •  Sender/Receiver dependency
  23. 23. Communication paradigms •  Typical communication patterns •  Synchronous request/response •  Asynchronous commands
 (with known receiver) •  Asynchronous events
 (without known receiver)
  24. 24. The “synchronous request/response everywhere” trap
  25. 25. Why are we doing it?
  26. 26. Remember the “one-size-fits-all” trap?
  27. 27. Yes, but why this paradigm?
  28. 28. Why synchronous R/R? •  “It’s how the internet works” •  “The library support is better” •  “It is easier to reason about” •  Matches the way we consciously think •  Matches the way we learned to do design
  29. 29. Do not forget the other side of the coin
  30. 30. The flipside of the coin •  HTTP was designed for a specific use case •  Access hypermedia content •  Not an ubiquitous communication solution •  The world outside a process is different •  Non-determinism kills easy reasoning •  Latency creep kills easy reasoning •  Solution mismatch adds complexity •  Compromises functional encapsulation •  Changes and extensions become more complicated •  Longer activation paths compromise robustness
  31. 31. Designing communication
  32. 32. An (invidious) example …
  33. 33. Order fulfillment
  34. 34. Let us begin with the well-known
 synchronous request/response design ...
  35. 35. Order fulfillment Initial version with limited functionality
 •  Order includes •  Items •  Amounts •  Price per item •  Total price •  Credit card payment •  Only non-digital items
  36. 36. Order Fulfillment
 Service Online Shop Payment
 Service Credit Card Provider Shipment
 Service Warehouse System <Foreign Service> <Own Service> Credit Card Coordinate Warehouse
  37. 37. Order fulfillment Add coupons
 •  Order additionally includes •  Optional coupon ID •  Optional remaining coupon value •  Coupon is already charged against total price •  Validate coupon
  38. 38. Order Fulfillment
 Service Online Shop Payment
 Service Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Coupon Credit Card Coordinate Warehouse Coordinate Credit Card Provider
  39. 39. Order fulfillment Add promotions
 •  Order additionally includes •  Optional promotion ID •  Promotion is already applied to order •  Notify Campaign Management System about promotion usage
  40. 40. Order Fulfillment
 Service Online Shop Payment
 Service Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Coupon Campaign Management Promotion Credit Card Coordinate Warehouse Coordinate Credit Card Provider
  41. 41. Order fulfillment Add customer accounts
 •  Order additionally includes •  Payment type (Credit card/Account) •  Charge customer account
  42. 42. Order Fulfillment
 Service Online Shop Payment
 Service Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Accounts Receivables Coordinate Warehouse Credit Card Provider Coupon Promotion Credit Card Coordinate
  43. 43. Order fulfillment Add PayPal
 •  Order additionally includes •  More payment types (Credit card/PayPal/Account) •  Payment via PayPal
  44. 44. Order Fulfillment
 Service Online Shop Payment
 Service Credit Card Provider Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Promotion Campaign Management Account service Payment provider PayPal Accounts Receivables Coupon Credit Card Coordinate Warehouse PayPal Coordinate
  45. 45. Order fulfillment Add digital music library
 •  New shipment method •  Activate music assets in digital music library •  Notify customer via email including access link •  Digital music library has its own API
  46. 46. Order Fulfillment
 Service Online Shop Payment
 Service Credit Card Provider Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Promotion Campaign Management Account service Payment provider PayPal Accounts Receivables Music Library E-Mail Server Coupon Credit Card Coordinate Warehouse Coordinate Music Notify Cust. PayPal Coordinate
  47. 47. Order fulfillment Add digital video library
 •  New digital shipment channel •  Activate video assets in digital video library •  Notify customer via email including access link •  Digital video library has its own API •  Different from the music library API
  48. 48. Order Fulfillment
 Service Online Shop Payment
 Service Credit Card Provider Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Promotion Campaign Management Account service Payment provider PayPal Accounts Receivables Music Library Video Library E-Mail Server Coupon Credit Card Coordinate Warehouse Coordinate Assets Notify Cust. PayPal Coordinate
  49. 49. Order fulfillment Add e-book library
 •  New digital shipment channel •  Activate e-books in e-book library •  Notify customer via email including access link •  E-Book library has its own API •  Different from the other asset library APIs
  50. 50. Order Fulfillment
 Service Online Shop Payment
 Service Credit Card Provider Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Promotion Campaign Management Account service Payment provider PayPal Accounts Receivables Music Library E-Book Library Video Library E-Mail Server Coupon Credit Card Coordinate Warehouse Coordinate Assets Notify Cust. PayPal Coordinate
  51. 51. Order fulfillment Add bonus card
 •  Order additionally includes •  Optional bonus card ID •  Potential discount is already applied to order •  Notify Loyalty Management System about customer purchase
  52. 52. Order Fulfillment
 Service Online Shop Payment
 Service Credit Card Provider Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Promotion Campaign Management Loyalty Account service Payment provider PayPal Loyalty Management Accounts Receivables Music Library E-Book Library Video Library E-Mail Server Coupon Credit Card Coordinate Warehouse Coordinate Assets Notify Cust. PayPal Coordinate
  53. 53. Order fulfillment More requirements to come …
  54. 54. Order Fulfillment
 Service Online Shop Payment
 Service Credit Card Provider Shipment
 Service Warehouse System <Foreign Service> <Own Service> Coupon Management Promotion Campaign Management Loyalty Account service Payment provider PayPal Loyalty Management Accounts Receivables Music Library E-Book Library Video Library E-Mail Server Coupon Credit Card Coordinate Warehouse Coordinate Assets Notify Cust. PayPal Coordinate Synchronous request/response – findings “Divide and conquer” design •  Tight service coupling •  including cross-domain coupling •  Long activation paths •  Latency creep •  Availability erosion •  Underlying design assumption is 100% availability of all services used •  Complex orchestration logic in services •  including cross-service transactions •  New downstream services require changes of upstream services •  including knowledge about how to access downstream services in upstream services
  55. 55. Let us repeat the design
 using asynchronous events ...
  56. 56. Order fulfillment
  57. 57. Order fulfillment Initial version with limited functionality
 •  Order includes •  Items •  Amounts •  Price per item •  Total price •  Credit card payment •  Only non-digital items
  58. 58. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Credit Card Service Warehouse Service Payment authorized <Event> Payment failed
  59. 59. Order fulfillment Add coupons
 •  Order additionally includes •  Optional coupon ID •  Optional remaining coupon value •  Coupon is already charged against total price •  Validate coupon
  60. 60. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Credit Card Service Warehouse Service Payment authorized <Event> Payment failed Coupon Management Coupon Service
  61. 61. Order fulfillment Add promotions
 •  Order additionally includes •  Optional promotion ID •  Promotion is already applied to order •  Notify Campaign Management System about promotion usage
  62. 62. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Credit Card Service Warehouse Service Promotion Service Coupon Service Payment authorized <Event> Payment failed
  63. 63. Order fulfillment Add customer accounts
 •  Order additionally includes •  Payment type (Credit card/Account) •  Charge customer account
  64. 64. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Credit Card Service Accounts Receivables Warehouse Service Promotion Service Coupon Service Payment authorized Payment failed <Event>
  65. 65. Order fulfillment Add PayPal
 •  Order additionally includes •  More payment types (Credit card/PayPal/Account) •  Payment via PayPal
  66. 66. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Credit Card Service Accounts Receivables PayPal PayPal Service Warehouse Service Promotion Service Coupon Service Payment authorized Payment failed <Event>
  67. 67. Order fulfillment Add digital music library
 •  New shipment method •  Activate music assets in digital music library •  Notify customer via email including access link •  Digital music library has its own API
  68. 68. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Credit Card Service Accounts Receivables Music Library E-Mail Server PayPal PayPal Service Warehouse Service Promotion Service Coupon Service Music Library Service Notification Service Payment authorized Digital asset provisioned Payment failed <Event>
  69. 69. Order fulfillment Add digital video library
 •  New digital shipment channel •  Activate video assets in digital video library •  Notify customer via email including access link •  Digital video library has its own API •  Different from the music library API
  70. 70. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Credit Card Service Accounts Receivables Music Library Video Library E-Mail Server PayPal PayPal Service Warehouse Service Promotion Service Coupon Service Music Library Service Video Library Service Notification Service Payment authorized Digital asset provisioned Payment failed <Event>
  71. 71. Order fulfillment Add e-book library
 •  New digital shipment channel •  Activate e-books in e-book library •  Notify customer via email including access link •  E-Book library has its own API •  Different from the other asset library APIs
  72. 72. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Credit Card Service Accounts Receivables Music Library E-Book Library Video Library E-Mail Server PayPal PayPal Service Warehouse Service Promotion Service Coupon Service Music Library Service Video Library Service E-Book Library Service Notification Service Payment authorized Digital asset provisioned Payment failed <Event>
  73. 73. Order fulfillment Add bonus card
 •  Order additionally includes •  Optional bonus card ID •  Promotion is already applied to order •  Notify Loyalty Management System about customer purchase
  74. 74. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Credit Card Service Loyalty Management Accounts Receivables Music Library E-Book Library Video Library E-Mail Server PayPal PayPal Service Warehouse Service Promotion Service Bonus Card Service Coupon Service Music Library Service Video Library Service E-Book Library Service Notification Service Payment authorized Digital asset provisioned Payment failed <Event>
  75. 75. And how do we figure out if a business transaction eventually completes?
  76. 76. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Credit Card Service Loyalty Management Accounts Receivables Music Library E-Book Library Video Library E-Mail Server PayPal PayPal Service Warehouse Service Promotion Service Bonus Card Service Coupon Service Music Library Service Video Library Service E-Book Library Service Notification Service Order fulfillment supervisor Payment authorized Digital asset provisioned Payment failed <Event> Track flow of events. Reschedule events in case of failure Services are responsible to eventually succeed or fail for good, usually incorporating a supervision/escalation hierarchy for that
  77. 77. Order confirmed Online Shop Credit Card Provider Warehouse System <Foreign Service> <Own Service> Coupon Management Campaign Management Account service Credit Card Service Loyalty Management Accounts Receivables Music Library E-Book Library Video Library E-Mail Server PayPal PayPal Service Warehouse Service Promotion Service Bonus Card Service Coupon Service Music Library Service Video Library Service E-Book Library Service Notification Service Payment authorized Digital asset provisioned Payment failed <Event> Order fulfillment supervisor Track flow of events Reschedule events in case of failure Services are responsible to eventually succeed or fail for good, usually incorporating a supervision/escalation hierarchy for that Asynchronous events – findings “Go with the flow” design •  Services and domains decoupled •  Very short activation paths •  High responsiveness •  High availability •  No design assumptions about availability of services •  Coordination via choreography •  No central coordination and cross-service transactions •  Instead functional compensation logic in external supervision service •  New services can be integrated without touching existing services •  Services only focus on their task (no knowledge about other services required)
  78. 78. Didn’t we miss any special cases that
 would lead to very different findings?
  79. 79. Some special cases Synchronous request/response design •  Current order status •  E.g., pass status through call chain •  Maybe additionally extend order fulfillment service to store status in an status information database •  Payment failed •  E.g., stop processing in fulfillment service and send back appropriate status to online shop •  Cashing coupon failed •  E.g., extend payment service to place task in desk officer’s inbox •  Integrate new video library (different API) •  Adapt shipment service to new API •  Make sure not to disrupt other service aspects
  80. 80. Some special cases Asynchronous events design •  Current order status •  E.g., track events with a new service and store
 them in an status information database •  Payment failed •  E.g., track dedicated event with a new service
 that notifies customer and/or online shop •  Cashing coupon failed •  E.g., send out dedicated event that a new service subscribes to •  New service then places task in desk officer’s inbox •  Integrate new video library (different API) •  Implement new service •  Replace existing service with new service
  81. 81. Feels a lot like recurring patterns …
  82. 82. What did we learn so far?
  83. 83. Comparing the paradigms … •  Decomposition •  Vertically divide-and-conquer vs. horizontally go-with-the-flow •  Coordination •  Coordination logic/services and orchestration vs. event chains and choreography •  Transactions •  Built-in transaction handling vs. external supervision •  Error handling •  Built into service vs. escalation/supervision strategy •  Separation of concerns •  Multiple responsibilities service vs. single responsibility services •  Encapsulation •  Domain logic distributed across services vs. domain logic in one place •  Complexity •  A draw …
  84. 84. Different communication paradigms lead to very different service designs … which means different options to address a given problem
  85. 85. Related areas and limitations
  86. 86. Mixing communication paradigms
  87. 87. Mixing paradigms •  Always an option •  Note the trade-off between design purity and solution mismatch complexity •  A (very) simple heuristic •  Single functionality •  All-or-nothing characteristic •  Single domain Ø  Synchronous request/response •  Multiple functionalities •  Flow/Process characteristic •  Multiple domains Ø  Asynchronous messaging
  88. 88. What if the paradigm is fixed?
  89. 89. Fixed paradigm •  You can simulate other paradigms •  E.g., simulate sync. r/r with async. messaging •  E.g., simulate async. commands with sync. r/r •  Will support the service design topic •  Apart from that it is a (lame) compromise
  90. 90. What about user interaction?
  91. 91. User interaction •  Interaction with user client is usually r/r •  Use web sockets if available •  Use the mediator pattern with timeouts •  Could be implemented via a BFF service •  Complement with processing status page
  92. 92. Can we apply the same patterns inside process boundaries?
  93. 93. Inside process boundaries •  Have the process context in mind •  Without threads •  If your downstream call dies, you are also dead •  Usually synchronous r/r is appropriate •  Otherwise single-threaded scheduler is needed •  With threads •  “Multi-process light” •  Better multi-threading resilience possible •  More design options
  94. 94. Wrap-up •  The one-size-fits-all trap •  Communication paradigms •  The synchronous-r/r-everywhere trap •  Designing communication •  Influence on service design Different communication paradigms
 lead to very different service designs
  95. 95. There is no “one-size-fits-all” solution
  96. 96. @ufried Uwe Friedrichsen | uwe.friedrichsen@codecentric.de | http://slideshare.net/ufried | http://ufried.tumblr.com

×