Microservices have a strong reputation: split your software into separate services and you can adapt, scale and replace each part on its own. Those advantages are real. But they come with a price tag that most advantage lists leave out, and for many organisations a well-built monolith is the wiser choice.
So the question isn’t whether microservices offer advantages, but whether those advantages outweigh the extra complexity in your situation. You can make that call without writing a line of code yourself. What it mainly takes is knowledge of your own organisation.
One system or a collection of separate services
In a monolithic architecture, your application forms one whole: one codebase, one deployment. Change something, and you put the entire system live again. Microservices split that same system into independent parts, say a separate service for user management, one for payments and one for reporting. Each service is developed, tested and rolled out on its own.
That sounds like a detail for developers, but it determines how your organisation can work with the software: who can work on what, what grinds to a halt during an outage, and where you add capacity when things get busy.
Where the gains lie
Take a customer service application where the chat function is used heavily all day, while the reporting module is mostly active around the monthly close. With microservices, you give only the chat service extra capacity; the rest of the system stays untouched. In a monolith, you’re forced to scale everything at once, including the parts that don’t need it.
The same applies to outages. If the reporting service fails in that setup, chat and order processing keep running. And when several teams work on the system, each team can roll out its own service without waiting for the others. We describe more broadly how software can grow with your organisation in how custom software scales with business growth.
The price you pay for it
Every service you add is also one you have to run. It has its own deployment, its own monitoring and its own outages. What was an internal function call in a monolith becomes network traffic between services, traffic that can stall. Data ends up spread across several services and still has to stay consistent. And tracing a fault means searching through multiple systems instead of one log.
That overhead calls for a team that’s at home in distributed systems, and an organisation that can carry that management load. Without it, the advantages on paper get lost in the complexity in practice.
Four questions that sharpen the decision
Whether microservices pay off for your custom software mainly depends on four things:
- Do several teams work on the system and get in each other’s way at release time?
- Does the load differ so much between parts that scaling them separately makes a noticeable difference to performance or cost?
- Do parts need to keep running when another part fails?
- Does one part of the system change much faster than another?
Answer most of these questions with yes, and the architecture is worth investigating. Answer them with no, and microservices mainly buy you management overhead.
When you’re better off without them
An internal planning tool for a single department, maintained by one team, with a predictable load: splitting a system like that up doesn’t make it better. What suits it is a modular monolith, one application that’s tightly divided internally into modules with clear boundaries. That gives you much of the same clarity, without every part needing its own infrastructure.
A setup like that also keeps the door open. If the system grows and the need for separate services later becomes real after all, the boundaries along which you can split it are already there. Starting with a monolith is then not a setback but a saving.
If you’re facing this choice yourself, our main advice is this: let the architecture follow from your organisation, not the other way round. That’s why, when developing custom applications, we start with those four questions, and only choose the technology once it fits the answer.