Modular Monolith Architecture: A Practical Guide and When to Choose It Over Microservices

#modularmonolith

This article was originally published on bmf-tech.com.

Overview

This is a memo on what I researched about modular monoliths.

What is a Modular Monolith?

A monolith divided into modules
- While domain-based division is commonly seen, various patterns such as functional or technical division can be considered
Like a monolith, it has a single deployment pipeline
Benefits
- Modules are divided, allowing independent development per module
- Easier transition to microservices
- Easier to progress with microservice conversion per module
  - When transitioning from a monolith to microservices, it can be positioned as a strangler pattern (though it may not always be easy)
- Easier to review module boundaries, allowing more flexible adaptation to boundary changes compared to microservices
Drawbacks
- Easier to cross module boundaries
- Microservices communicate over a network, preventing boundary crossing, but modular monoliths do not, so care must be taken with boundary violations
- Like a monolith, it has a single deployment pipeline, so if it becomes bloated or module dependencies become complex, operation becomes difficult
- If each module shares a single database, the cost of transitioning to microservices increases

Service Weaver

Google has released a tool called Service Weaver for developing as a modular monolith and deploying as microservices.

Impressions

I had a bit of a dream about modular monoliths, but my impression led me to write a poem.

I think it's logical that architecture needs to evolve with organizational expansion, but I wondered if there might be a silver bullet architecture that can flexibly respond to organizational scalability or doesn't incur excessive costs. (There isn't.)

Organizations may expand, contract, or remain unchanged, but since companies assume growth, I thought it might be good to invest proactively in organizational scalability.

I wanted to quote a passage related to this topic, so I'll include it here to conclude.

However, what we need to focus on here is the difference in lifecycle between the two. Organizational and team configurations can be changed the next day depending on the company's policy if desired. However, architecture and systems are difficult to change quickly like an organization.

cf. eh-career.com - Reasons for Transitioning to a Modular Monolith ─ Asoview's Large-Scale Efforts to Balance Microservice Autonomy and Monolith Consistency