Microservices vs Monoliths: breaking free from architectural dogma

I often think about the evolution of system architecture, particularly the popularity of microservices. I observe how discussions on this topic excite the environment and how many myths and dogmas have grown around this approach. I would like to share my thoughts, which have emerged from observing market trends and the experiences of many companies.

Monolith vs microservices: motivations and challenges

Let's start with the basics: the original purpose of microservices was to enable teams to independently deploy software and increase speed. It looks great in theory. In practice, however, I have noticed that the main motivation for companies to switch to microservices is to manage large teams of engineers who are starting to get in each other's way while working on the same, often overloaded, monolithic project. The monolith becomes a bottleneck, and microservices seem to be the only solution.

Complexity and technical debt of microservices

However, I have a feeling that microservices, although they may initially increase the speed of a single team's work, eventually become a significant technical debt. They introduce significant complexity: even the slightest change can require numerous deployments, and collaboration between teams becomes more challenging as each service must operate flawlessly. What was meant to solve communication problems often leads to the creation of a 'distributed monolith', where dependencies are hidden and problems related to them appear at the most unexpected moments.

For me, microservices are primarily a social and technical problem. Technical challenges, such as maintaining all services and ensuring data consistency, are inextricably linked to human behavior. This includes reluctance to update dependencies, a lack of clear guidelines on responsibility for services, and duplication of logic.
It is often said that microservices should not share databases. Although this makes sense in theory, in practice, I see that companies, striving to achieve business goals as quickly as possible, often ignore this principle. Sharing databases becomes a compromise that blurs the line between monoliths and microservices, leading to even greater chaos and difficulty in managing data.

Success story: DoorDash's transformation

I have also observed success stories, such as the transformation of DoorDash, which had to switch to microservices because its monolithic architecture could not cope with the sudden increase in traffic during the pandemic. In such cases, despite all the challenges, the transition was necessary for the company to survive and continue to develop. This shows that sometimes it's not a matter of choice, but necessity. Today, DoorDash has hundreds of services, and an average front-end request results in a thousand RPC calls – a scale that cannot be achieved otherwise.

Dogmatism in programming and architecture

I often find dogmatic approaches to programming irritating. The blind pursuit of 100% test coverage without understanding that it doesn't always translate into quality and can hinder code refactoring is one of many examples. I believe that in software engineering, there are no golden rules that apply to every situation. Every architectural decision should be well thought out and adapted to the specific needs of the project and team.

The future of systems architecture – new directions

Looking to the future, I hope that the industry will create new abstractions and frameworks that offer a genuine alternative to the dichotomy of monoliths versus microservices. Current approaches, although they have their advantages, are far from ideal. Projects such as Google's Service Weaver are a step in the right direction — they demonstrate that we can strive for systems that offer the flexibility of microservices while minimizing their drawbacks.

Microservices are a tool, not a dogma

My observations lead me to conclude that microservices are a powerful tool, but they require enormous technical and organizational awareness and maturity. They are not a magic solution to all problems, and their implementation involves new, often complicated challenges. The key to success is understanding that there is no one "best" approach, and that every architecture should be an evolving system that adapts to changing business and technological needs..

Happy architecting!