Microservices? No, modularity is what matters
18 days ago
- #modularity
- #microservices
- #software-architecture
- Modularity is a crucial concept in software design, independent of architecture style (Monolith or Microservices).
- A module is a piece of software responsible for specific functionality, with defined public APIs for interaction.
- Benefits of modularity include organization, comprehension, resource utilization, reusability, and testability.
- Modularity should be considered as soon as two possible modules emerge in a system.
- Example system: 'Curious Notes to the Interesting Quotes' with modules for users, quotes, and notes.
- Physical architecture (Monolith or Microservices) should be secondary to logical module separation.
- Real-world challenges include partial knowledge and changing requirements, favoring simpler modular monoliths initially.
- Implementation strategies range from simple modular monoliths to complex microservices, each with tradeoffs.
- Simple Modular Monolith: modules as folders with conventions to maintain boundaries.
- Modular Monolith with Independently Deployable Modules: stricter isolation with versioned packages.
- Microservices: modules as separate applications, offering scalability but with high complexity.
- Constrained Microservices (Microliths): limit network calls during request handling to reduce complexity.
- Modular Monolith with Helper Services: core modulith with separate services for unique needs.
- Parallel work and independent deployments are possible with good modular design, regardless of architecture.
- Frontend modularity can follow similar principles, with options like code splitting or Micro Frontends.
- Closing thoughts emphasize thoughtful consideration of modularity strategies and favoring simplicity.