Good and Bad Monolith

After several years of the microservice hype, now it seems monoliths are cool again! Does it mean, we have learned a lesson?

I guess at least we accepted what Neal Ford stated in his book Building Evolutionary Architectures:

If you cant build a monolith, what makes you think microservices are the answer?

The disturbing question is: Why is monolith synonymous with a bad design for some and the right thing to do for others?

Two Kinds of Monolith

The reason is, there are two different kinds of a monolith: physical and logical. While one is mostly a good thing, the other is pure evil.

Physical Monolith

The first kind of monolith is what we usually picture under the word: a physical block of software, typically running as a single process.

A physically monolithic system is developed and built as a single artifact, deployed at once and falling down as a whole. Resources such as a database are often shared, communication is local, interprocess.

The opposite is then a distributed system composed of multiple physically independent components each running in its own process. Each component owns its resources and communication is done in a remote manner.

A physical monolith is no anti-pattern, its a good thing to start with as its easy to build, deploy, operate, and reason about.

Physically monolithic applications are pretty performant as there are no additional overheads in communication. Cross-cutting aspects are much simpler because no special platform (such as a service mesh) is needed.

As the system gets bigger, further partitioning is possible. A popular option is to apply a satellite architecture where bottleneck services are separated from the monolithic base.

Logical Monolith

The second kind is a logically monolithic system. Other names are the Big ball of mud, Spaghetti code, etc. Logically monolithic codebases lack boundaries (technologies are not service boundaries!), everything is coupled to everything, no visible architecture is to be found.

Logical monoliths are evil and dangerous constructs that cause high complexity and tight coupling of building blocks making development expensive and error-prone.

Logically monolithic software is unmaintainable on a scale and exponentially corrodes.

Modular and Distributed Monoliths

Doing things right or very wrong, you can end up with two types of systems: modular or distributed monolith, respectively.

Modular Monolith (Modulith)

The opposite of a logical monolith is a modular monolith (or, if you like, modulith). In a modular codebase business capabilities are worked out by services with explicit logical (not necessarily physical) boundaries.

A modular monolith is probably the best architectural approach for most applications. It's easy to extend, maintain, and reason about.

That is, moduliths are really cool!

Although the logical and physical natures of monoliths are independent, they often come hand in hand. Thats why people easily confuse them with each other.

As the boundaries in monolithic codebases are typically not physical its easy to cross them. A monolithic codebase, therefore, requires great discipline.

Distributed Monolith

A logically, but not physically, monolithic system is called a distributed monolith. Distributed monoliths have all drawbacks of distributed systems with almost no benefits.

While dealing with the Big ball of mud is pain, distributed monoliths are a real disaster.

Systems often end up as distributed monoliths while adapting the microservices approach incorrectly.

From Microservices to Monolith

The microservices movement in the last years promised us a lot. The catch is, microservices focus only on physical monoliths, not the logical ones.

To understand why we have to take a closer look at what microservices really attempt to solve.

A microservice is a service with some technical additions (independent development cycle). It is important to notice the word technical as the logically monolithic design is obviously a logical, not technical, issue, there is nothing microservices could potentially do for us!

Microservices propose a solution to tackle physical monoliths only. Thats the reason so many attempts to build microservices failed badly, simply because a wrong issue was addressed and the true problem got only bigger (and, even worse, distributed).

With the logically monolithic design, microservices dont come to the rescue, rather, to put down.

Services First

We can think of microservices as a specific approach to Service-oriented architecture (SOA).

There are several definitions of SOA, but we will focus mainly on the concept of a service, because it is the most significant. I use this modified service definition from Udi Dahan:

A service is the autonomous unit of logic for a specific business capability.

Now, it is obvious why microservices as such cant really help us with the logically monolithic design: monolithically designed microservices are no services at all, they are mere physical components!

The business only has the key to defining our services correctly. And only well-designed services can tackle logical monoliths and profit from the microservices approach.

Its a hard task, but Domain-driven design can help us a lot!

Conclusion

If you struggle with your monolithic system, the problem may likely lie in its logically monolithic design.

The physical nature of the monolith is usually a secondary problem, easy to solve after the proper service-oriented design has been applied.

Once the logical monolith is resolved, microservices architecture is just one step further...

Originally published on my blog.