What Makes a Monolith Monolithic?

 

It seems like everybody throws around the term “monolith”, but what do we mean by that?

Sam Newman started the ball rolling yesterday with this tweet:

I'm at that point in the new book where I have to define what monolith means. Bugger.

— Sam Newman (@samnewman) July 25, 2017

My first response was a (semi) joke:

that's just semantics...[looks at the definition of "semantics"]...bugger

— Gene Hughson (@GeneHughson) July 25, 2017

I say semi joke because, in truth, semantics (i.e. meaning) is critical. The English language has a horrible tendency to overload terms as it is, and in our line of work we tend to make it even worse. Lack of specificity obscures, rather than enlightens. The problem with the term “monolith” is that, while it’s a powerfully evocative term, it isn’t a simple one to define. My second response was closer to an actual definition:

yep...IMO it's more about meta-coupling - even multiple binaries/process could still be monolithic, particularly w/ shared data stores

— Gene Hughson (@GeneHughson) July 25, 2017

The purpose of this post is to expand on that a bit.

The “mono” portion of the term is, in my opinion, the crucial part. I believe that quality of oneness is what defines a monolithic system. As I noted in the second tweet, it’s a matter of meta-coupling, whether that coupling exists in the form of deployment, data architecture, or execution style (Jeppe Cramon‘s post “Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 3” shows how temporal coupling can turn a distributed system into a runtime monolith). The following tweets between Anne Currie and Sam illustrate the amorphous nature of what is and isn’t a monolith:

know at least 2 companies who code independent microservices but compile services together as a single process to deploy (dev vs run speed)

— Anne Currie (@anne_e_currie) July 25, 2017

They consider they produce microservices. They deploy separately where resilience needs outweigh execution speed ones. We do need terms 😉

— Anne Currie (@anne_e_currie) July 25, 2017

I think in this example you have three things - service endpoints, modules, and microservices.

— Sam Newman (@samnewman) July 25, 2017

When lots of them bundled together, you have multiple modules each exposing a service endpoint. When deployed separately - microservices

— Sam Newman (@samnewman) July 25, 2017

Modules that can be deployed to run in a single process need not be considered monolithic, if they’re not tightly coupled. Likewise, running distributed isn’t a guarantee against being monolithic if the components are tightly coupled in any way. The emphasis on “in any way” is due to the fact that any of the types of coupling I mentioned above can be a deal killer. If all the “microservices” must be deployed simultaneously for the system to work, it’s a distributed monolith. If the communication is both synchronous and fault intolerant, it’s a distributed monolith. If there’s a single data store backing the entire system, it’s a distributed monolith. It’s not the modularity that defines it (you can have a modular monolith), but the inability to separate the parts without damaging the whole system.

I would also point out that I don’t consider “monolithic” to be derogatory, in and of itself. There is a trade-off involved in terms of coupling and complexity (and cost). While I generally prefer more flexibility, there is always the danger of over-engineering. If we’re hand-carving marble gargoyles to stick on a tool shed, chances are the customer won’t be pleased. The solution should bear at least a passing resemblance to the problem context it’s supposed to address.