If you’ve spent any time in the IT world, chances are you’ve heard the term microservices more times than you can count. It’s one of those concepts that seems to pop up in every tech discussion, conference talk, and architecture diagram.
Microservices have been a buzzword for years—and they still are. Everyone talks about them, everyone praises them, and sooner or later, almost every team feels the pressure to adopt them.
There’s even an unspoken assumption in the industry:
If your project isn’t using microservices, it must be outdated or not ambitious enough.
Sounds familiar?
It almost feels like the IT industry is under a spell—completely captivated by the promise of microservices. But have you ever stopped to ask why this architectural style became so popular in the first place?
The rise of cloud computing played a huge role. Platforms like AWS, Azure, and GCP made distributed systems easier to build and scale. Add containerization into the mix—especially with tools like Docker and Kubernetes—and suddenly microservices felt not just possible, but inevitable.
On top of that, countless blogs, conference talks, and success stories have glorified microservices as the ultimate solution to scalability, flexibility, and rapid development.
But here’s the part that often gets overlooked.
Microservices are not a silver bullet. While they solve certain problems very effectively, they also introduce a new set of challenges—often far more complex than those faced in monolithic systems. Issues like service communication, data consistency, monitoring, debugging, and operational overhead can quickly spiral out of control if not handled carefully.
Like any architectural choice, microservices come with trade-offs. And in many cases, the problems they introduce can be harder to manage than the ones they were meant to solve.
Before jumping on the microservices bandwagon, it’s worth asking a simple but critical question:
Some of the biggest challenges posed by microservices are, among others:
Let us now consider whether we all really need microservices? The vast majority of companies from the IT industry do not need microservices, they simply do not reach the scale where microservices can show what they can do in all their glory. Here it is mainly about the scale of the system we have, if we are not a company like Netflix, Shopify, etc. We probably will not see any benefits from using microservices also, I think we will only hurt ourselves, in many respects, also financially, because as already I mentioned earlier, microservices can consume a lot of resources, and this results in a lot of money.
Naturally, the first alternative became the monolith, that we all know already. Used for ages, hated by most people, but traditional monolith is not that bad as people think. It is all again a matter of scale. For minor projects developed by small development teams, it is almost perfect architecture.
Press enter or click to view image in full size
Monolith Architecture
For simple CRUD systems, MVP, etc., no fancy architecture is needed. But what if we know that our application will grow, we know that the domain we are working on is demanding?
Modular Monolith Architecture comes with the help hand. How is it different from a traditional monolith? And why is it better? First, Modular Monolith is composed of modules. Each module must complete a few requirements.:
Of course, there is no way that each module will be completely independent from the rest of the system, but we have to keep it as independent as it possible. Each module only links to code that it specifically needs.
Innovating, designing, and developing solutions that redefine how the digital world connects, learns, and grows.