Microservices: Redundancy=Maintainability
11 likes3,585 views
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.
Ad
More Related Content
Viewers also liked (13)
Similar to Microservices: Redundancy=Maintainability (20)
Ad
More from Eberhard Wolff (15)
Ad
Recently uploaded (20)
Microservices: Redundancy=Maintainability
- 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!
- 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. LI 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!
- 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
- 38. ECommerce System Order Catalog Billing Search Module = separate deployment units! Communication e.g. REST
- 39. REST REST
- 42. ECommerce System Order Catalog Billing Search Dependencies between systems cannot sneak in “Architecture Firewalls”
- 43. “Architecture Firewall” like REST enforce the architecture
- 48. ECommerce System Order Catalog Billing Search Components small Hard to mess up Replace if messed up.
- 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
- 58. Every information should be stored and updated in one place.
- 59. No redundancy for our product data!
- 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.
- 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.
- 79. Address for calculating the drones’ routes VALUE OBJECT ENTITYor
- 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
- 88. A central, redundancy-free data model is the optimum.
- 89. A central, “redundancy-free” data model is often hard to maintain and wrong.
- 92. Redundant code: The ultimate sin > Fix bug in many different place > Decisions implemented in many places > ...and hard to change
- 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 abstractionChange!
- 109. System System System System abstractionChange! Impact Impact Impact
- 110. System System System System abstractionChange! Impact Impact Impact
- 111. Now we have reuse …and a dependency.
- 112. Dependency not just in software!
- 113. System System System System common abstractionChange! 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
- 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