Microservices: what the term means for business
A breakdown of what actually sits behind the word 'microservices' and how a manager should think about this architectural choice.
The word "microservices" is coming up more and more in conversations with development teams. Sometimes it is a well-grounded proposal. Sometimes it is a buzzword covering a desire to rewrite everything from scratch. For a manager, the important thing is to understand what is actually behind it before agreeing or refusing.
The architectural choice here is real, and it has practical consequences for development speed, maintenance cost, and the company's ability to change. But it also carries risks that tend to stay offscreen in enthusiastic presentations.
What a monolith is and why it stops working
Most enterprise systems started as monoliths - a single application where everything is connected to everything else. That is not bad at the start: simpler to build, simpler to test, simpler to deploy.
The problem appears later. Once the system has grown, any change in one part requires understanding everything else. The team is afraid to touch "working" code. Releases slow down. New features are added with one eye always on everything that already exists. This is the specific pressure that made the case for fewer monoliths and more architectural discipline.
This is usually where the conversation about alternatives begins.
What microservices propose
The idea is simple: break a large application into independent pieces, each of which does one thing and communicates with the rest through clearly defined interfaces.
The theoretical benefits:
- different teams can work on different parts independently;
- each part can be updated and deployed separately;
- a problem in one part does not take the whole system down;
- different parts can be scaled individually.
That sounds convincing. But there is another side to it.
What stays offscreen
A microservices architecture solves scaling problems but creates new operational complexity. Instead of one application, you have to operate dozens or hundreds. Each with its own deployment, monitoring, logging, and versioning.
Network calls between services are unreliable. You need to think about what happens when one service is unavailable. Transactions that were atomic in the monolith are now distributed across several systems - that is its own class of problems.
And then there is the organisational point: service independence only works if teams are genuinely independent. If three teams are constantly waiting on each other, the architecture does not help.
When it makes sense
Breaking a monolith into microservices is justified when:
- the system is genuinely large and several teams are getting in each other's way during development;
- different parts of the system have fundamentally different requirements for load and reliability;
- there is operational maturity - the team knows how to run distributed systems;
- there is time and budget for the transition, not just for building new features.
If a company is still finding its product-market fit, premature decomposition will likely slow things down, not speed them up. The same trade-offs apply whether the question is an architectural choice or a management decision.
Questions for the conversation with your team
Before making an architectural decision, I recommend getting clear answers to these questions:
- What specific problem are we solving with this architecture - what exactly is not working right now?
- How many teams will work with the system and how genuinely independent are they today?
- Do we have experience running distributed systems, or will we be acquiring it on the job?
- What is the migration plan - rewrite from scratch or extract parts gradually?
- How will the cost of maintenance change one year after the transition?
Architecture is not a religion. It is a tool, and it should be chosen for the specific task at hand.