Microservices: Redundancy=Maintainability
11 likes3,589 views
The document discusses reshaping software architecture through microservices to enhance maintainability and replaceability, emphasizing the importance of clean architecture and code. It highlights the pitfalls of redundancy in code and data, advocating for modular systems that enable independent deployment and reduced dependencies. The microservices manifesto underscores the prioritization of replaceability, bounded contexts, and independence over traditional approaches like 'don't repeat yourself'.
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