What is a Modular Monolith? Architecture Comparison

Lately, we've been seeing the term modular monolith a lot, but what is it? Why are we seeing it so much these days? Here, we'll explore what it is, the reasons, and different types of system architectures that are commonly seen today.

1 - What is a monolith?

Before explaining the modular monolith, I feel obligated to at least explain the monolith itself.

In the post about microservices, we already covered what a monolith is and its characteristics, etc., so I'll summarize it very simply. A monolith, or a monolithic application, is an application that contains all the business logic, the entire frontend, the entire database, etc.

These applications are usually characterized by being very large, requiring a lot of maintenance, and, of course, the complexity of developing in them, because under normal circumstances, there is no domain separation, and everyone accesses everything from everywhere, etc.

The main problem is what I just mentioned: absolutely everything is interconnected, and changing functionalities is very difficult because it affects other parts of the system that shouldn't be impacted, but since everything is so interconnected, it happens.

This makes development a nightmare, and surprisingly, we still see code like this today, in fact, it's far more common than it may seem.

The main problem with this architecture is that "nobody" actually owns anything. For example, anyone can update any database record from anywhere, etc. This makes everything very difficult to maintain; for example, if you want to modify something that already exists to add a validation or to change a column or something similar, it ends up being a massive task instead of a simple change, which it would be if everyone respected the boundaries of what they are allowed to modify.

2 - What is a modular monolith?

A modular monolith is a monolith built properly, with structure and not just thrown together haphazardly.

The main difference is that in modular monoliths, the boundaries of each section are completely separated.

Architecturally, it’s still a single application, but its boundaries are separated, which avoids most of the problems developers face when making changes to the monolith.

When we say boundaries are separated, we mainly mean that the logic layer is separated. The UI layer or the database itself may or may not be separated, both options have pros and cons. But the main point is that the logic layer is separated.

Then, each module has an interface or entry point so that other modules can query or change information, etc., and not do this directly in the database.

This is the main feature of modular monoliths: to help with development. When it comes to deploying the application, it still has the same pros and cons as a regular monolith: the same scaling challenges (for example, you can't scale just one part); modular monoliths are closely tied to Domain Driven Design, with limited domains, etc.

In my opinion, this should currently be the go-to option if you have to build a monolith. Make it modular; building a monolith like in the past is basically long-term suicide.

3 - Microservices

I already have a post where I explain what microservices are, so I won't go into detail here. To summarize: small services that communicate with each other, and the main feature is that each has its own database, its own business layer, etc. In short, they are isolated systems but offer an entry point so other services can query their information.

This information can be accessed via synchronous communication like REST or asynchronous communication such as the producer-consumer pattern.

4 - Microliths

Special mention to microliths: and what are microliths, you might ask? It’s a term I coined to refer to those projects that managers call microservices, but they are just as big or bigger than a monolith, inheriting the disadvantages of both monoliths and microservices, simply because they were developed poorly, very poorly, and without any planning.

I'm sure all of you reading this have worked with systems like these at some point.

5 - What is serverless?

To sum up quickly what serverless is, we can say it's a way of running applications without having to manage any servers.

Of course, it's not running in the ether; the server is typically managed by a cloud provider, whether Azure, Amazon, Google Cloud, etc. They provide the infrastructure and you pay for its usage, with things like scaling and availability included in the price.

For example, Azure Functions or Lambda Functions are how Azure and AWS execute code (functions) within their infrastructure (there are more examples, but these are typical). You create your small application in the language of your choice and deploy it to the service, and you only pay each time it runs. If it runs once a month, it's nearly free, and if it runs 1,000 times per second, it's going to cost a lot.

This form of development is known as "cloud-native development." It's the most modern, relieves the development team of the most responsibility, and, of course, is the most expensive.

And the most common thing you find in the real world is a mix of cloud-native along with architectures like microservices (mainly on Kubernetes) or even a monolith.

6 - The rise of the modular monolith

The main reason I created this post is because of the rise of modular monoliths. If you've seen any talks in the last 12 or 24 months, you'll have noticed they are being mentioned more and more. But why is that?

The reason is clear and simple: managing microservices is complicated to some extent, and a monolith is much simpler. Also, if needed and if we've built the modular monolith correctly, it can be "split" easily into microliths, and then each microlith into its respective microservice, if necessary.

Personally, I've worked on a project like this, and it's much easier than splitting a microservice as such.