Modular Monoliths and Other Facepalms
Analysis of the report on why the “modular monolith” is not a new style, but a return to the engineering discipline: information hiding, module boundaries and verifiable dependencies.
Report
Modular Monoliths and Other Facepalms
Kevlin Henney speaks at NDC London about modularity, boundaries and the cost of distribution.
Main idea
The problem is often in the decomposition rather than in the deployment format
Microservices do not automatically cure bad boundaries, but only increase the cost of errors.
Limitation
Estimated timecodes
Without an official transcript, the semantic blocks of the video are roughly analyzed and marked separately.
Source
Microservices
Definition of microservices and basic trade-offs independent deployability.
Main points of the report
"Modular monolith" is a return to the engineering base
The focus is that modularity, information hiding and componentization existed long before microservices.
Microservices were often chosen as forced partitioning
A common motive: to force a division of a system when there are no longer healthy boundaries within the monolith.
False dichotomy: "monolith vs microservices"
The architecture is judged by the quality of boundaries and dependencies, not by the number of processes.
Historical principles of decomposition are still relevant
Parnas, ADT and component thinking as practical supports for architecture today.
Distribution reinforces bad architecture
Transferring a bad structure to the network creates the same chaos, but is more expensive to operate.
Practical conclusion: modular monolith first
Start from a modular monolith and incremental allocation of services based on sustainable drivers.
Timeline visualization
The evolution of "modularity" as a discipline (in terms of primary sources)
D. Parnas - decomposition criteria, information hiding
Formalization of the idea that a module should hide implementation details and fix stable boundaries.
Liskov & Zilles - abstract data types (ADT) and extensible abstractions
Strengthening the design approach through data abstractions and a contractual style of interaction.
Foote & Yoder - Big Ball of Mud pattern (evolution anti-pattern)
It is shown how, without discipline and boundaries, the system naturally collapses into a lump of dependencies.
Lewis & Fowler - definition of microservices as a set of independently deployable services
Emphasizes that the value of microservices comes from independent deployment, not from a fancy shortcut.
Simon Brown - "distributed big balls of mud" as a risk of distributed degradation
Distribution increases the cost of architectural mistakes if boundaries are not drawn up in advance.
"Modular monolith" as a pendulum/rebranding of the modularity discussion
Reframe: This is a return to a basic engineering discipline rather than the emergence of a new architectural style.
Conclusions for developers
- Modularity is a property of dependencies and contracts, not of the infrastructure and the number of services.
- Turn architecture into testable rules: loops, prohibit traversal of layers, direction of imports.
- Calling a system modular monolith is not enough: the boundaries must be firmly expressed in code and CI.
- Select services only based on stable business boundaries and a clear need for independent deployment.
Conclusions for tech leads
- Make modular monolith the default strategy and microservices a sound investment.
- Budget for the cost of distribution: observability, security, delivery-platform, data-consistency.
- Manage the architecture with structure metrics: forbidden dependencies, cycles, drift between modules.
- Formalize module ownership and architectural violation policy (baseline + debt reduction plan).
Practical plan for 2-4 weeks
- 1Fix 3-7 modular boundaries and assemble a dependency graph by code.
- 2Add 5-10 architectural rules to CI (layers, cycles, forbidden imports).
- 3Include a baseline approach: a ban on the growth of violations + a plan for their gradual burning.
- 4Only review service candidates where there are independent SLAs/release cycles.
When to stay in a monolith and when to spin out services
Modular monolith as default
If independent deployment is not a sustainable requirement, it is better to invest in modular boundaries, architecture tests and ownership within a single process.
Microservices as a conscious step
Select services when there are clear drivers of independent deployability, separate SLAs, scaling in parts and readiness for the cost of distribution.
Risks and limitations
- Timecodes for scenes in the report are of a reconstructive nature and are not a transcript.
- The transition to microservices without mature boundaries often leads to distributed monolith and an increase in operational load.
- The label "modular monolith" without testable dependency rules quickly becomes marketing hype.