Monoliths vs Microservices: attempting to avoid passions

Introduction

Millions of lines have been written about the monolith vs microservices debate. This is a sterile debate in my opinion, as you should make technical decisions based on facts rather than on emotions and feelings. Anyway, I just can't ignore the debate if I am willing to provide the best information I can about microservices.

The challenges of distributed computing

Distributed computing -and microservices are distributed by nature- has some of the most complex challenges computing has. This is something we cannot -and should not- hide.

• Communication through networks is challenging. The network is not reliable, it has latency, and bandwidth is not infinite. And is not secure or, at least, it needs a lot of work to make it as safer as possible.
• Infrastructure is complex: building the infrastructure for a single component is not the same as building it for a set of distributed components, many times in different networks, with different resources, programming languages, etc.
• Testing a single component is easy. Testing the integration of multiple ones is not. At all.
• Monitoring a distributed system is not easy, as you have to consider latencies, network failures, and other kinds of related issues. But, at the time, is completely necessary.

Why then, if distributed systems and microservices have all these issues, should I choose a microservices architecture over the simpler, easy-to-develop monolith approach?

But, first, we need to talk about the debate itself. It is actually fair?

An unfair debate

If you read articles over the Internet about the microservices vs monoliths thing, you will find some very well-written articles with several valid points. But you will also find millions of other articles with lots of fallacies.

To begin, we need to avoid the unfair debate that compares perfect monoliths with the worst possible microservices architecture that a team of developers can build. It is obvious to me that both approaches have challenges to solve in order to be successful, so it is very unfair to talk about monoliths that fixed all of these issues and microservices-based approaches that just ignored all of the complexities of this architecture and failed again and again.

For example, communication between microservices is often an example of a huge challenge people have when developing microservices. And then the comparators say "you don't have these issues in a monolith". But, isn't true that monoliths many times need to communicate with external services such as external providers? What then? Aren't monoliths then forced to solve the very same issues as microservices?

We also need to consider also the fallacy of the self-fulfilling prophecy: many times, the teams that try to build microservices architectures and fail and blame the approach try this because they are tired of the monolith being a big ball of mud. So, the same people that were not able to build a decent monolith are now building microservices. And fail. How could have known?

Choosing the best possible option

The reason why you should choose microservices over monoliths is that the requirements of your product match better with the characteristics of the microservices than with the ones of the monoliths. As simple as that. Like any other engineering decision ever.

If you have a company with multiple teams that need to be split through the software; if you have different needs in terms of resource allocation; if your domain requires different programming languages for different functionalities. If you have a capable team.

If some of this applies to you, probably you should go to a microservices architecture. And then, you should be prepared for the challenges. Exactly the same as with any other kind of decision in engineering. Pros and cons. Advantages and disadvantages. I would say even the same as with any other decision in life.

And remember. The other possible decision -in this case choosing a monolith- has also disadvantages. Monoliths are very big, so they have challenges in terms of code changes conflicts, the testing run and deployment process being very slow, the inability to use different languages for different proposes, etc.