The traditional monolith approach and its problems

The traditional approach to the software when developing a system has been to create a monolith. This is a fancy word to say a single element, containing everything, and it is the way virtually every project starts. In the context of web applications, that means creating deployable code that can be replicated so that requests can be directed to any of the deployed copies:

After all, every project will start off small. Making strict divisions early on is inconvenient and even doesn't make sense. A newly created project is small and probably handled by a single developer. While the design can fit in the head of a few people, making strict boundaries between parts of the system is counterproductive.

But things change, successful software grows and, after some time, having a big ball of code is maybe not the best way of structuring a big project.

Monoliths can have, in any case, internal structure, meaning they don't necessarily get into the realms of spaghetti code. It may be perfectly structured code. What defines a monolith is the requirement to deploy the system as a whole, without being able to make partial deployments.

As the monolith grows, some of its limitations will start to show up:

• The code will increase in size: Without strict boundaries between modules, developers will start having problems understanding the whole code base. While good practices can help, the complexity naturally tends to increase, making it more difficult to change the code in certain ways and increasing subtle bugs. Running all tests will become slow, decreasing the speed of any Continuous Integration system.
• Inefficient utilization of resources: Each individual deployed web worker will require all the resources required for the whole system to work, for example, the maximum amount of memory for any kind of request, even if a request that demands a lot of memory is rare and just a couple of workers will be sufficient. The same may happen with the CPU. If the monolith connects to a database, each individual worker will require a connection to it, whether that's used regularly or not, and so on.
• Issues with development scalability: Even if the system is perfectly designed to be horizontally scalable (unlimited new workers can be added), as the system grows and the development team grows, development will be more and more difficult without stepping on each other's toes. A small team can coordinate easily, but once several teams are working on the same code base, the probability of clashing will increase. Imposing boundaries for teams in terms of ownership and responsibility can also become blurry unless strict discipline is enforced. In any case, teams will need to be actively coordinated, which reduces their independence and speed.
• Deployment limitations: The deployment approach will need to be shared across teams, and teams can't be individually responsible for each deployment, as deployment will probably involve work for multiple teams. A deployment problem will bring down the whole system.
• Interdependency of technologies: Any new tech needs to fit with the tech in use in the monolith. A new technology, for example, a tool that's perfect for a particular problem, may be complicated to add to the monolith, due to a mismatch of technologies. Updating dependencies can also cause issues. For example, an update to a new version of Python (or a submodule) needs to operate with the whole code base. Some required maintenance tasks, such as a security patch, can cause a problem just because the monolith already uses a specific version of a library, which will break if changed. Adapting to these changes requires extra work too.
• A bug in a small part of the system can bring down the whole service: As the service is a whole, any critical issue that affects the stability affects everything, making it difficult to generate quality service strategies or causing degraded results.

As you can see in the examples, most of the monolith issues are growing issues. They are not really important unless the system has a sizeable code base. There are some things that work very well in monoliths, such as the fact that, because there are no boundaries in the code, the code can be changed very quickly and efficiently. But as teams grow and more and more developers are working in the system, boundaries help to define objectives and responsibilities. Too much flexibility becomes a problem in the long term.