Microservices: Redundancy=Maintainability

Microservices: Redundancy=Maintainability

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.

2350801025b8e8592dbaa8dd98a24cbb?s=128

Eberhard Wolff

June 16, 2016
Tweet

Transcript

  1. Microservices: Redundancy = Maintainability! Eberhard Wolff @ewolff Fellow innoQ

  2. http://continuous-delivery-buch.de/

  3. http://microservices-buch.de/ http://microservices-book.com/

  4. http://microservices-book.com/primer.html FREE!!!!

  5. Maintainablity Redundant data Redudant code

  6. Legacy System

  7. None
  8. Too many dependencies Cyclic dependencies (dotted lines)

  9. > COBOL, Assembler > Not maintainable > Not replaceable

  10. L

  11. > We will replace it! > We will make it

    maintainable! > It will be beautiful!
  12. We will take good care of the code!

  13. Clean Like Spring

  14. Clean Architecture

  15. Developer

  16. Developer

  17. Result?

  18. None
  19. > Legacy System > Java > Not maintainable > Not

    replaceable
  20. L

  21. > We didn’t try hard enough! > We will replace

    it! > We will make it maintainable! > It will be beautiful!
  22. L I need a new job.

  23. While there are still developers: Replace the legacy system. Repeat

  24. Insanity: Doing the same thing over and over again and

    expecting different results. Albert Einstein
  25. We can achieve maintainability with clean architecture + clean code.

  26. We can achieve maintainability with clean architecture + clean code.

  27. Clean approach tried often. Results?

  28. Lots of Legacy Code …and secure jobs.

  29. We need a different approach!

  30. Parnas 1972 Modules

  31. ECommerce System Order Catalog Billing Search

  32. Modules by Domain > Each domain problem solved in one

    module. > New features easy to add
  33. Modules > Programming language feature > Class, package, library …

    > Rather weak modules
  34. Developer

  35. Microservices > Modules > Separate deployment units > Separate VM

    / process
  36. Server Server Micro Service Micro Service

  37. ECommerce System Order Catalog Billing Search Module = separate deployment

    units!
  38. ECommerce System Order Catalog Billing Search Module = separate deployment

    units! Communication e.g. REST
  39. REST REST

  40. ECommerce System Order Catalog Billing Search Dependencies between systems cannot

    sneak in
  41. ECommerce System Order Catalog Billing Search Dependencies between systems cannot

    sneak in
  42. ECommerce System Order Catalog Billing Search Dependencies between systems cannot

    sneak in “Architecture Firewalls”
  43. “Architecture Firewall” like REST enforce the architecture

  44. ECommerce System Order Catalog Billing Search Components small

  45. ECommerce System Order Catalog Billing Search Components small Hard to

    mess up
  46. ECommerce System Order Catalog Billing Search Components small Hard to

    mess up
  47. ECommerce System Catalog Billing Search Components small Hard to mess

    up
  48. ECommerce System Order Catalog Billing Search Components small Hard to

    mess up Replace if messed up.
  49. Small, independent deployable modules are recyclable.

  50. Recycle your software! !

  51. How many people are trying to replace legacy systems?

  52. Replaceability is usually no goal for a software project. Why??

  53. We can achieve maintainability with clean architecture + clean code

  54. We can achieve maintainability with architecture firewalls + recyclable modules

  55. Maintainability

  56. Redundancy

  57. Redundancy Redundant data

  58. Every information should be stored and updated in one place.

  59. No redundancy for our product data!

  60. ECommerce System Products database

  61. ECommerce System Invoicing System Products database

  62. ECommerce System Invoicing System Products database Products database

  63. ECommerce System Products database Invoicing System

  64. ECommerce System Products database Invoicing System Purchase System

  65. ECommerce System Products database Invoicing System Purchase System Marketing System

  66. Products data model?

  67. None
  68. No redundancies High complexity Hard to change

  69. A central, redundancy-free data model is the optimum.

  70. A central, redundancy-free data model is the optimum.

  71. UBIQUITOUS LANGUAGE VALUE OBJECT ENTITY

  72. Address VALUE OBJECT ENTITY or

  73. 529 pages Part IV Chapter 14

  74. A domain model is only useful in a Bounded Context.

  75. There is no universal data model in a large system.

  76. Let me repeat:

  77. There is no universal data model in a large system.

  78. Address for a customer VALUE OBJECT ENTITY or

  79. Address for calculating the drones’ routes VALUE OBJECT ENTITY or

  80. ECommerce System Products Invoicing System Purchase System Marketing System

  81. ECommerce System Invoicing System Purchase System Marketing System BOUNDED CONTEXT

    BOUNDED CONTEXT BOUNDED CONTEXT BOUNDED CONTEXT
  82. Create a model for each BOUNDED CONTEXT.

  83. Each BOUNDED CONTEXT can be a Microservice with its own

    database schema
  84. Low complexity Easy to change i.e. easy to maintain

  85. None
  86. Few redundancies Separate facets

  87. ECommerce System Invoicing System Purchase System Marketing System Product: Image

    Product: Price Product: Supplier Product: Brochure
  88. A central, redundancy-free data model is the optimum.

  89. A central, “redundancy-free” data model is often hard to maintain

    and wrong.
  90. Redundancy Redundant data 

  91. Redundancy Redundant code

  92. Redundant code: The ultimate sin > Fix bug in many

    different place > Decisions implemented in many places > ...and hard to change
  93. DRY Don’t Repeat Yourself

  94. DRY Systems? Great! DRY between systems? DRY is a trade-off

  95. System System System System common common common common

  96. System System System System common abstraction

  97. Reuse: The Holy Grail of the nineties So where are

    all the reusable internal frameworks?
  98. Premature optimization, that’s like a sneeze. Premature abstraction is like

    Ebola; it makes my eyes bleed. Christer Ericson
  99. The entire history of software engineering is that of the

    rise in levels of abstraction. Grady Booch
  100. Using code is hard. Reusing code is almost impossible. But

    we are reusing Open Source all the time!
  101. Create an Open Source project!

  102. Open Source > Good code quality > Documentation > Model

    to accept contributions
  103. “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?”
  104. Let’s assume it’s possible to reuse code. Reuse is still

    a tradeoff.
  105. System System System System common common common common

  106. System System System System abstraction

  107. System System System System abstraction Change!

  108. System System System System abstraction Change!

  109. System System System System abstraction Change! Impact Impact Impact

  110. System System System System abstraction Change! Impact Impact Impact

  111. Now we have reuse …and a dependency.

  112. Dependency not just in software!

  113. System System System System common abstraction Change! Impact Impact Impact

  114. Dependency between teams Coordination Meetings Getting no real work done

  115. L

  116. Reuse is a tradeoff: Reuse vs. Independence Independence= Easy to

    change= Maintainability
  117. Independence is important for self-organization. Self-organization = deciding yourself Not

    meetings upon meetings
  118. Deciding yourself is only possible, if teams and modules are

    independent.
  119. Redundancies between systems must be avoided.

  120. Redundancies between systems must be avoided.

  121. Reuse is a tradeoff: Reuse vs. Independence

  122. Microservices focus on independence

  123. The Microservices Manifesto ;-)

  124. Microservices Manifesto ;-) We value: Replaceability over maintainability

  125. Microservices Manifesto ;-) We value: BOUNDED CONTEXT over redundancy-free data

  126. Microservices Manifesto ;-) We value: Independence over “Don’t Repeat Yourself!”

  127. Replaceability over maintainability BOUNDED CONTEXT over redundant-free data Independence over

    DRY