Regrettably, the monolith has ended up being a dirty word. A physical monolith is usually the ideal thing to do. the opposite is monolithic reasoning.
After numerous years of the microservices buzz, it currently appears that monoliths are great once again! Does this mean we have learned a lesson?
I guess the very least we approved what Neal Ford mentioned in his book Building Evolutionary Architectures:
‘If you can’t build a monolith, what makes you think microservices are the answer?’
The troubling concern is: Why is monolith associated with a poor design for some and yet the ideal thing to do for others?
Two Types of Monolith
The fact is, there are two different types of monolith: physical and logical. While one is mainly a good thing, the other is pure wickedness.
Physical Monolith
The first type of monolith is what we typically imagine under the word: a physical block of software, usually running as a single process.
A physically monolithic system is developed and constructed as a single artifact, released simultaneously all at once and falling in its entirety. Resources such as a database are frequently shared, communication is local, interprocess.
Monolith
The reverse is then a dispersed system made up of several physically independent elements each operating in its very own process. Each component has its resources and communication is executed remotely.
Distributed system
A physical monolith is no anti-pattern, it is a good idea to start with as it is simple to build, deploy, operate, and reason about.
Physically monolithic applications are quite performant as there are no extra expenses in interaction. Cross-cutting aspects are much easier to the fact that no special platform (such as a service mesh) is required.
As the system grows, even more partitioning is feasible. A popular alternative is to use“satellite” architecture where bottleneck services are separated from the monolithic base.
Monolith with satellites
Logical Monolith
The second type is a logically monolithic system. Various other names utilized are Big ball of mud, Spaghetti code, etc. Logically monolithic codebases do not have limits, everything is paired to everything and no visible architecture is to be found.
Logical monolith
Logical monoliths are evil and unsafe constructs that create high complexity and limit coupling of building blocks making development expensive as well as error-prone.
Logically monolithic software is unmaintainable on a scale and exponentially rusts.
Modular and Dispersed Monoliths
By doing things right or very wrong, you will end up with one of the couple 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 exercised by services with explicit logical (not always physical) boundaries.
A modular monolith is most likely the most effective architectural technique for most applications. It is easy to expand, preserve, and reason about.
That means moduliths are truly cool!
Modular monolith (modulith)
Although the logical and physical natures of monoliths are independent, they frequently go together. That is why people easily confuse them with each other.
As the boundaries in monolithic codebases are typically not physical it is easy to cross them. A monolithic codebase, as a result, needs excellent discipline.
Distributed Monolith
A logically, however not physically, the monolithic system is called a distributed monolith. Distributed monoliths have all the disadvantages of distributed systems with practically none of the benefits.
While handling with the huge ball of mud is a pain, distributed monoliths are an actual disaster.
Distributed monolith
Systems commonly end up as distributed monoliths while adjusting the microservices come close to incorrectly.
From Microservices to Monolith
In the last years, the microservices movement promised us a lot. The catch is, microservices only concentrate on physical monoliths, not logical ones.
To understand why we need to check out what microservices really try to solve.
A microservice is a service with some technological enhancements (independent development cycle). It is essential to keep in mind the word “technical” — as the logically monolithic design is undoubtedly a logical, not technical, issue, there is absolutely nothing microservices could potentially do for us!
Microservices suggest a solution to handle physical monoliths only. That is the reason why a lot of attempts to build microservices fell shortly, simply because the wrong issue was addressed and the true problem only got bigger (and, even worse, distributed).
With the logically monolithic design, microservices do not come to the rescue, much more the opposite.
Services First
We can consider microservices as a specific method to Service-oriented design (SOA).
There are several definitions of SOA, yet we will certainly focus primarily on the idea of service because it is the most considerable. 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 cannot help us with the logically monolithic design: monolithically designed microservices are no services at all, they are simple physical components!
Business alone has the key to properly specifying our services. Only well-designed services can deal with logical monoliths and profit from the microservices approach.
It is a tough task, but Domain-driven design can help us a lot!
Conclusion
If you have a problem with your monolithic system, this may likely lie in its logically monolithic design.
The physical nature of the monolith is generally an additional 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…
Types of systems by physical and logical architecture