Think of a monolith architecture as a system that needs to be changed and deployed as a single entity. Development teams work on different modules of this entity, Testing teams run tests on the system and then it is eventually deployed as a single entity to users.

Contrary to what many think, a monolith is a great way to build software. It is simple to develop and easy to monitor, debug and test.

There is strength in its simplicity.

However, there are downsides as well. It is hard to change a single module independent of other modules. It can be difficult to scale, as the database can be tricky to decompose.

I have seen teams work on monolith software that was in large parts ‘spaghetti’ mixed with a healthy portion of legacy code that was never refactored. This monolith required massive effort just to get it work together more modern software.

Distributed Monolith? Just say no

One situation that you want to avoid is a distributed monolith. This is a monolith where teams have managed to separate their software into modules, however the modules are still tightly coupled. This means that you cannot change, deploy and release software modules independently. If that’s the case, then your team is not really gaining any benefit from a distributed system. Just the overheads.

I must emphasise again that a Monolith does not automatically imply a poorly designed, legacy system. Many successful startups like Netflix, Airbnb etc. all started with Monolith Architectures. Basecamp is a great example of a well executed and intentional monolith.

Distributed systems and specifically Microservices are often seen as an alternative to Monoliths. More on that and how you should approach such a transition in the next post.