Are we witnessing a shift from the age-old “monolithic vs microservices-based architecture” debate to a... "modular monolith vs microservices" dilemma?
But what is a modular monolithic approach, more precisely? And how is it better than a “non-modular” monolithic app architecture?
What makes it a viable and tempting alternative to a microservices-based one?
Hadn't we settled this matter already?
A service-oriented architecture is “the next big thing”, while everything monolith-related is just... messy, chaotically structured code, right?
Well, apparently it turns out that:
- microservices aren't the answer to all type of needs
- … they do present some disadvantages, as well
- there's no need to get tangled up in the complexities (and accept the inevitable latency) of deploying and debugging a whole infrastructure of microservices if your team's size and your scaling needs don't call for it
- a modular monolithic approach to your app's architecture is the middle way between monoliths' well-known limitations and inconveniences and microservices' higher level of complexity
But, let's get straight to it: here's a modular monolith vs microservices analysis that will (hopefully) give you all the answers you need to... make a choice:
Let's Recap the Main Drawbacks & Limitations of a Monolithic Architecture
“A big ball of mud is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design.” (Big Ball of Mud, Brian Foote, and Joseph Yoder)
This still makes one of the most accurate definitions of a monolithic architecture.
A definition that's also a short “inventory” of its well-known disadvantages:
- cobbled
- hard to maintain
… ball of code.
Myth buster: trying to turn a poorly structured monolith into a distributed architecture will only get you a... poorly structured, yet distributed architecture.
Summing up, we can say that there are 2 typical signs that we're dealing with a monolithic architecture:
- a single codebase
- a single artifact
In other words, a monolithic approach suits you if your needs don't go beyond packaging and distributing your app.
But if they're more complex than that, and your app architecting scenario calls for coupling and for multiple, well-defined interfaces, you'll find this approach quite... limited.
The Microservices Architecture: When Benefits Turn into... Disadvantages
"... if people can't build monoliths properly, microservices won't help" Simon Brown.
I totally agree with Simon Brown's statement. In such a case, you'd only manage to end up with a distributed big ball of... code, nothing more sophisticated than that.
Still, we can't deny that there are clear benefits of adopting a microservices-oriented approach if/when there's the need and the right context to leverage them to the fullest:
- versioning
- releasing
- scaling
… services individually.
If your scaling needs — whether it's your team or your app that you need to scale up — warrant these benefits, they do become powerful. And valuable enough to compensate for inherent drawbacks like increased complexity and latency.
But if:
- you're just trying to improve your cobbled, messy code structure through a distributed architecture
- you have a team of... 5 (or less) engineers
- there's no clear justification for... splitting up your application
- its components and their interfaces are not properly defined
- your app's standing on a poor architecture
… these benefits can easily turn into a... dread.
Just imagine that:
- it's a whole ecosystem of apps that you'll need to debug
- at times, different components of your apps might be down
- deploying such a heavy infrastructure of parts, spread across multiple repos, gets way more challenging
- coding in independent services becomes a true dare
Modular Monolith vs Microservices
Now, what if the size of your team and your scaling needs don't justify the inevitable complexities and latency of a microservices-based architecture?
But you're not really tempted by its alternative — a monolithic architecture — either...
Good news! You can build your monolithic system as a set of modular components. Multiple, loosely coupled app components, easy to maintain and with properly-defined interfaces...
Note: well-structured code is key to putting together an efficient, easily maintainable modular monolithic system. Remember that this is the closest thing you'll get to that agile architecture “promised” by the microservices approach. And a badly structured, messy code won't take you anywhere close to “microservicizing” your app...
Let's take this example:
You're building a web app with a 3-tier layered structure: a business logic, a web, and a database access layer.
A modular monolithic architecture allows you to bundle all these components — the database access routines, the business logic ones, the web-related parts — into separate layer packages.
Key benefits:
- you'll get interchangeable implementations if your interfaces remain the same
- having a modular app will allow you to easily scale up both your team and your software
- you get to update multiple services all at once
And, finally, a “modular monolith vs microservices” analysis comes down to:
Not having to go through X projects managers, from X different projects, each one with its own “ecosystem” of deployment oder dependencies, just to... implement a new feature.
The END!
Have I managed to shed some light? Is it any clearer for you now whether a modular monolithic architecture or a microservices-oriented one best suits your scaling needs?