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.

Microservices: Redundancy=Maintainability

2,405 views

Published on

We assume software should contain no redundancies and that a clean architecture is the way to a maintainable system. Microservices challenge these assumptions. Keynote from Entwicklertage 2016 in Karlsruhe.

Published in: Technology
  • Be the first to comment

Microservices: Redundancy=Maintainability

  1. 1. Microservices: Redundancy = Maintainability! Eberhard Wolff @ewolff Fellow innoQ
  2. 2. http://continuous-delivery-buch.de/
  3. 3. http://microservices-buch.de/ http://microservices-book.com/
  4. 4. http://microservices-book.com/primer.html FREE!!!!
  5. 5. Maintainablity Redundant data Redudant code
  6. 6. Legacy System
  7. 7. Too many dependencies Cyclic dependencies (dotted lines)
  8. 8. > COBOL, Assembler > Not maintainable > Not replaceable
  9. 9. L
  10. 10. > We will replace it! > We will make it maintainable! > It will be beautiful!
  11. 11. We will take good care of the code!
  12. 12. Clean Like Spring
  13. 13. Clean Architecture
  14. 14. Developer
  15. 15. Developer
  16. 16. Result?
  17. 17. > Legacy System > Java > Not maintainable > Not replaceable
  18. 18. L
  19. 19. > We didn’t try hard enough! > We will replace it! > We will make it maintainable! > It will be beautiful!
  20. 20. LI need a new job.
  21. 21. While there are still developers: Replace the legacy system. Repeat
  22. 22. Insanity: Doing the same thing over and over again and expecting different results. Albert Einstein
  23. 23. We can achieve maintainability with clean architecture + clean code.
  24. 24. We can achieve maintainability with clean architecture + clean code.
  25. 25. Clean approach tried often. Results?
  26. 26. Lots of Legacy Code …and secure jobs.
  27. 27. We need a different approach!
  28. 28. Parnas 1972 Modules
  29. 29. ECommerce System Order Catalog Billing Search
  30. 30. Modules by Domain > Each domain problem solved in one module. > New features easy to add
  31. 31. Modules > Programming language feature > Class, package, library … > Rather weak modules
  32. 32. Developer
  33. 33. Microservices > Modules > Separate deployment units > Separate VM / process
  34. 34. Server Server Micro Service Micro Service
  35. 35. ECommerce System Order Catalog Billing Search Module = separate deployment units!
  36. 36. ECommerce System Order Catalog Billing Search Module = separate deployment units! Communication e.g. REST
  37. 37. REST REST
  38. 38. ECommerce System Order Catalog Billing Search Dependencies between systems cannot sneak in
  39. 39. ECommerce System Order Catalog Billing Search Dependencies between systems cannot sneak in
  40. 40. ECommerce System Order Catalog Billing Search Dependencies between systems cannot sneak in “Architecture Firewalls”
  41. 41. “Architecture Firewall” like REST enforce the architecture
  42. 42. ECommerce System Order Catalog Billing Search Components small
  43. 43. ECommerce System Order Catalog Billing Search Components small Hard to mess up
  44. 44. ECommerce System Order Catalog Billing Search Components small Hard to mess up
  45. 45. ECommerce System Catalog Billing Search Components small Hard to mess up
  46. 46. ECommerce System Order Catalog Billing Search Components small Hard to mess up Replace if messed up.
  47. 47. Small, independent deployable modules are recyclable.
  48. 48. Recycle your software! !
  49. 49. How many people are trying to replace legacy systems?
  50. 50. Replaceability is usually no goal for a software project. Why??
  51. 51. We can achieve maintainability with clean architecture + clean code
  52. 52. We can achieve maintainability with architecture firewalls + recyclable modules
  53. 53. Maintainability
  54. 54. Redundancy
  55. 55. Redundancy Redundant data
  56. 56. Every information should be stored and updated in one place.
  57. 57. No redundancy for our product data!
  58. 58. ECommerce System Products database
  59. 59. ECommerce System Invoicing System Products database
  60. 60. ECommerce System Invoicing System Products database Products database
  61. 61. ECommerce System Products database Invoicing System
  62. 62. ECommerce System Products database Invoicing System Purchase System
  63. 63. ECommerce System Products database Invoicing System Purchase System Marketing System
  64. 64. Products data model?
  65. 65. No redundancies High complexity Hard to change
  66. 66. A central, redundancy-free data model is the optimum.
  67. 67. A central, redundancy-free data model is the optimum.
  68. 68. UBIQUITOUS LANGUAGE VALUE OBJECT ENTITY
  69. 69. Address VALUE OBJECT ENTITYor
  70. 70. 529 pages Part IV Chapter 14
  71. 71. A domain model is only useful in a Bounded Context.
  72. 72. There is no universal data model in a large system.
  73. 73. Let me repeat:
  74. 74. There is no universal data model in a large system.
  75. 75. Address for a customer VALUE OBJECT ENTITYor
  76. 76. Address for calculating the drones’ routes VALUE OBJECT ENTITYor
  77. 77. ECommerce System Products Invoicing System Purchase System Marketing System
  78. 78. ECommerce System Invoicing System Purchase System Marketing System BOUNDED CONTEXT BOUNDED CONTEXT BOUNDED CONTEXT BOUNDED CONTEXT
  79. 79. Create a model for each BOUNDED CONTEXT.
  80. 80. Each BOUNDED CONTEXT can be a Microservice with its own database schema
  81. 81. Low complexity Easy to change i.e. easy to maintain
  82. 82. Few redundancies Separate facets
  83. 83. ECommerce System Invoicing System Purchase System Marketing System Product: Image Product: Price Product: Supplier Product: Brochure
  84. 84. A central, redundancy-free data model is the optimum.
  85. 85. A central, “redundancy-free” data model is often hard to maintain and wrong.
  86. 86. Redundancy Redundant data
  87. 87. Redundancy Redundant code
  88. 88. Redundant code: The ultimate sin > Fix bug in many different place > Decisions implemented in many places > ...and hard to change
  89. 89. DRY Don’t Repeat Yourself
  90. 90. DRY Systems? Great! DRY between systems? DRY is a trade-off
  91. 91. System System System System common common common common
  92. 92. System System System System common abstraction
  93. 93. Reuse: The Holy Grail of the nineties So where are all the reusable internal frameworks?
  94. 94. Premature optimization, that’s like a sneeze. Premature abstraction is like Ebola; it makes my eyes bleed. Christer Ericson
  95. 95. The entire history of software engineering is that of the rise in levels of abstraction. Grady Booch
  96. 96. Using code is hard. Reusing code is almost impossible. But we are reusing Open Source all the time!
  97. 97. Create an Open Source project!
  98. 98. Open Source > Good code quality > Documentation > Model to accept contributions
  99. 99. “But high quality Open Source is hard. We just share code!” “You only provide high quality as Open Source… ...but for colleagues low quality is OK?”
  100. 100. Let’s assume it’s possible to reuse code. Reuse is still a tradeoff.
  101. 101. System System System System common common common common
  102. 102. System System System System abstraction
  103. 103. System System System System abstraction Change!
  104. 104. System System System System abstractionChange!
  105. 105. System System System System abstractionChange! Impact Impact Impact
  106. 106. System System System System abstractionChange! Impact Impact Impact
  107. 107. Now we have reuse …and a dependency.
  108. 108. Dependency not just in software!
  109. 109. System System System System common abstractionChange! Impact Impact Impact
  110. 110. Dependency between teams Coordination Meetings Getting no real work done
  111. 111. L
  112. 112. Reuse is a tradeoff: Reuse vs. Independence Independence= Easy to change= Maintainability
  113. 113. Independence is important for self-organization. Self-organization = deciding yourself Not meetings upon meetings
  114. 114. Deciding yourself is only possible, if teams and modules are independent.
  115. 115. Redundancies between systems must be avoided.
  116. 116. Redundancies between systems must be avoided.
  117. 117. Reuse is a tradeoff: Reuse vs. Independence
  118. 118. Microservices focus on independence
  119. 119. The Microservices Manifesto ;-)
  120. 120. Microservices Manifesto ;-) We value: Replaceability over maintainability
  121. 121. Microservices Manifesto ;-) We value: BOUNDED CONTEXT over redundancy-free data
  122. 122. Microservices Manifesto ;-) We value: Independence over “Don’t Repeat Yourself!”
  123. 123. Replaceability over maintainability BOUNDED CONTEXT over redundant-free data Independence over DRY

×