Modular Monolith: Is This the Trend in Software Architecture? (Category Architecture)
Interesting and short whitepaper It's about modular monoliths, which asks questions about their trendiness. The authors of the article made Systematic Grey Literature Review (SGLR) to analyze this issue. In fact, this is an analysis of materials that have not passed a commercial academic publication. (reports of departments and NGOs, dissertations, conference reports, technical specifications, preprint repositories, project sites, etc.). They tried to understand how common modular monoliths are, strategically combining the ease of developing traditional monoliths with the benefits of microservices scalability, offering an alternative that avoids the complexities of distributed systems while maintaining modular principles. The question was whether modular monolith could become a viable compromise for the best of both worlds. The study is motivated by the announcement of the framework Service Weaver from Google, which allows you to write applications as modular monoliths with the possibility of microservice depletion. Google Service Weaver itself answered this question. 6 In June, he will go to the archives without reaching the required level of adoption.
But going back to the whitepaper itself, the authors tried to show that modular monolith provides: Maintaining the development speed characteristic of monoliths Clear module boundaries that prevent evolution into the Big Ball of Mud Flexibility of use as an independent architecture or an intermediate stage before microservices Simplification of debugging and testing processes Effective scaling of commands through module allocation
From the literature study, they identified the following key characteristics of modular monoliths: - Segregation of modulesIndependent modules with their own layers (Domain, Infrastructure, API) - Modularityweak connectivity and strong connectivity within modules, asynchronous communication via API - Unified Database Schema: a single database scheme instead of individual schemes for the service - Monolithic DeploymentAll modules operate within a single VM or are distributed over a dedicated VM - Unified Application ProcessA single application process for all scales - Enhanced MaintainabilityMeasurable improvement in maintenance vs. traditional monoliths
The study noted that the most famous companies with modular monoliths are Shopify, Appsmith, Gusto, PlayTech, however, they did not use Service Weaver.
P.S. If you step away from the whitepaper itself and evaluate the problems that led to the closure of Service Weaver, you can note the following: 1) Low adoption rate - in fact, it is written on the page of the project in the argumentation for its closure
We realized that it was hard for users to adopt Service Weaver directly since it required rewriting large parts of existing applications. Therefore, Service Weaver did not see much direct use, and effective December 5, 2024, we will transition Service Weaver into maintenance mode. **2) Just go stack.**This narrowed the target audience. 3) The danger of abstraction, where a local call can suddenly become an RPC (remote procedure call) This weaver is similar to the CORBA/RMI concept. 20 Years ago, she showed her impracticality. 4) Insufficient functionality The framework did not have ready-made routing/retries as in service mesh, no built-in mtls, no convenient monitoring. 5) Competition within the Google Cloud Most of the cases where weaver helped users already solved through Cloud Run, GKE Autopilot + Istio or Functions, that is, it was easier for them to use the usual stack than to learn a new CLI and TOML-configuration Weaver
In total, an interesting idea did not fly due to the fact that it did not gain a critical mass of users, and also did not offer an answer to conceptual questions such as local / remote procedure calls and their incomplete correspondence with each other in terms of NFT in different types of deployments. But for fans of modular monoliths, frameworks of the Spring Modulith type remained.
#Architecture #Whitepaper #DistributedSystems #SystemDesign #Software #Engineering