The 3 Reasons Why the Monolith Will Make You Less Agile

Friends don't let friends believe it's easier to get started on a monolith

Photo by Jon Butterworth on Unsplash

In the previous issue, we talked about how adopting serverless technologies is an effective way of making a team more agile.

This week, we will flip that point on its head and ask ourselves whether working with a traditional monolith can make us less agile!

Arguments in favour of building systems with a more distributed nature (microservices, ideally serverless-based) are fairly well known.

On the other hand, there are people and organisations advocating for the benefits of a monolithic system. On the surface, their arguments would appear to make sense. If you’re running a relatively small team, why would you subject yourself to the added complexity of a distributed architecture?

Here are 3 reasons why I believe that a monolithic application will make your team less agile and less effective:

#1 Increased Cognitive Load Is the Real Enemy

There is a common myth that an increase in infrastructure configuration is a problem. By contrast, the simplicity of the monolith is perceived as the dream state.

This line of thinking makes the mistake of focusing too heavily on technical infrastructure as opposed to human interaction and productivity. It’s a bad bargain!

Sure, it’s easy enough to spin up a couple of virtual servers, put a load balancer in front of them, and dump a monolith on it. A minimal serverless application will likely have a bit more than that to start with.

But that is a relatively minor problem as long as a team embraces DevOps practices, whereby every engineer has at least a working knowledge of how to set up the infrastructure she needs.

As Matthew Skelton and Manuel Pais (co-authors of the book Team Topologies) say:

We should be thinking about limiting the size of software, services, and products to the cognitive load that the team can handle.

It is very rare for an engineer to be capable of mastering a mid-to-large size monolith. Frankly, it is unhealthy to look for, never mind encourage, such a thing.

Teams should be able to easily, comfortably understand and own a portion of the system. Not the whole thing, or at least not in the same detail.