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.

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
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?
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?
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
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