Why You Should Split the Monolith

This is the first part of the series about defining right service boundaries.

The main trait of any organisation nowadays is probably business-agility. Business-agility is a measure indicating how fast your organisation can react on market changes, or, more globally, on environment changes, and introduce new solutions. So, in absence of business-agility any enterprise is doomed to failure — sooner or later. It is simply going to be uncompetitive.

So, the main trait of IT department, which is a part of any enterprise, is business-agility as well.

Let’s look at it a little bit deeper. When I, as a developer, face a new business requirement, be it either brand new business feature or some changing of the existing one, that requirement should be completed fast and without breaking any existing functionality. And it would be great if the development pace won’t slow down as the code base getting bigger. This is what I call the agility in IT department. And this is, once again, probably the main characteristic of that department.

And the only thing (ok, there are some more, but the main one) that prevents me from achieving this noble goal is system’s complexity, entanglement. Yes, I’m talking about codebase. But complexity is not the inherent trait of any software. There has not been any software in the world that has been complex from the very beginning. Complexity is the acquired feature. So, my goal is to defeat it.

What characteristic is at the origin of any software complexity? Before answering just recall how often you had to fix some code and guess what functionality could be affected? How many times you haven’t guessed? Quite often, have you? This is a manifestation of tight coupling. And it’s what prevents us from doing our job good and fast.

Monoliths inherently indulge tight coupling. It’s so easy to use any module’s class! OK, only this time, only here, because I don’t have time to make it right way, and I’m on my way to creating a technical debt task! Let’s face it, it’s not only this time. So it’s not only here. And business-guys don’t give a damn about technical debt tasks. As a result business processes implemented in our code intertwine in a myriad of non-predictable and completely-impossible-to-comprehend ways. A lot of implicit dependencies arise. The code is getting harder and harder to read and to change, and by fixing something in one place we get couple of more bugs in another.

So we all have come to a conclusion that instead of a monolith we need logically separated parts. How to define correctly the boundaries of these parts? How do these parts should communicate with each other?

For now I want to make my definitions clear. Parts that are the result of the monolith’s split can contain any number of physical servers which can contain both the backend code and UI data. There can be any number of databases inside these parts. They all can have different schemas. Or may not have. These databases can be located on one physical server. Or on more than one. From now and on I will call these logical parts, Lord forgive me, services.

In the next post, I will talk about the ways of defining service boundaries I’ve seen in the wild and that suffer from flaws of varying degree of severity.

Why You Should Split the Monolith was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.