There's an old carpentry proverb: when the only tool you have is a hammer, everything looks like a nail. Somewhere around 2015, the software industry handed every developer a hammer labelled "microservices" and told them Netflix used it. Ever since, we've been pounding perfectly good screws into the wall and wondering why the drywall keeps cracking. That's the microservices vs monolith debate in a nutshell: a great tool, used on the wrong problem.
Here's the uncomfortable truth from someone who has scoped, built, and rescued a lot of these systems: 99% of businesses do not have a Netflix problem. They have a "we need software that works and doesn't cost a fortune to run" problem. And for that problem, the right tool is usually a boring, reliable three-tier monolith.
The hammer is the pattern, not the problem. A microservices mesh makes an excellent hammer. Most businesses just don't have that particular nail.
The Origin Story Nobody Reads Past the Headline
Microservices weren't invented because they're fun to build (they're not). They were invented because companies like Netflix, Amazon, and Google hit a very specific wall:
- Thousands of engineers needed to ship independently without stepping on each other
- Individual components needed to scale to wildly different loads (imagine scaling your login service the same as your video encoding service)
- A single team owned each service end to end, on call for it, deploying it whenever they wanted
That's not a technology decision. That's an organizational one. Microservices are a solution to a people problem at massive scale, dressed up as an architecture pattern. Conway's Law, not computer science, is the real author of the microservices playbook.
If you have 6 developers and 200 customers, you do not have that problem. You have a different problem entirely: you need to ship features fast, keep the lights on cheaply, and not need a full-time platform team just to keep your "simple" CRUD app talking to itself.
The Cargo Cult Confession
Let's be honest about how a lot of microservices decisions actually get made:
- A senior dev read a great conference talk about how Company X scaled to a billion requests a day
- Nobody asked whether the business has a billion of anything
- "Microservices" looks great on a resume and in an architecture diagram for the next funding pitch
- Somebody said the word "scalability" in a meeting and the room nodded like it was a magic spell
I've walked into more than one client engagement where a two-person dev team was maintaining 14 microservices, a service mesh, and three message queues, for an app with maybe 400 daily active users. They weren't running a platform. They were running a distributed system whose only job was to make simple things complicated, one Docker container at a time.
What Premature Microservices Actually Cost You
This is the part the conference talks skip:
- Network calls everywhere. What used to be a function call is now an HTTP request that can time out, retry, or silently fail
- Debugging becomes archaeology. A single user action can touch six services, and now you need distributed tracing just to answer "why did this button not work"
- Deployment complexity multiplies. Instead of one build pipeline, you have a dozen, each with its own versioning, secrets, and failure modes
- Data consistency gets genuinely hard. Welcome to eventual consistency, distributed transactions, and the joy of explaining to a client why their order total is briefly wrong
- You need a platform team you don't have. Someone has to own service discovery, observability, and orchestration. That someone is usually your one senior developer, now permanently unavailable for actual feature work
None of this is imaginary. It's the bill that arrives eighteen months after the architecture diagram looked impressive in the kickoff meeting.
Same problem, two very different footprints. One of these is what almost every business actually needs. The other is what most businesses accidentally build.
Microservices vs Monolith: The Case for Boring
A three-tier monolith (frontend, backend, database, all deployed as one coherent unit) gets mocked for being unfashionable. It also happens to:
- Deploy in one step, not twelve
- Let one developer understand the whole system without a wiki full of service maps
- Scale vertically (bigger server) or with a couple of read replicas far longer than most businesses ever need
- Debug like normal software, because it is normal software
- Cost a fraction to host and maintain
Boring is not the same as bad. Boring is what lets a five-person company compete on features instead of spending its runway on Kubernetes YAML.
When Microservices Actually Earn Their Keep
To be fair to the hammer: sometimes it really is a nail. Consider it seriously when:
- Multiple teams genuinely need to deploy independently, several times a day, without coordinating
- One component has wildly different scaling or reliability needs than the rest of the system (a payment processor versus a marketing blog, for example)
- You have the operational maturity (and headcount) to run distributed systems properly, monitoring, tracing, on-call rotations included
If none of those describe your business today, they might describe it in three years. Good news: a well-built monolith with clean internal boundaries can be split into services later, when you actually feel the pain that justifies it. Building distributed from day one is optimizing for a problem you don't have yet, at the cost of the problem you do have: shipping.
| Concern | Monolith | Microservices |
|---|---|---|
| Deployment | One pipeline, one step | One pipeline per service, coordinated releases |
| Debugging | Normal stack traces | Distributed tracing required |
| Team size needed | Works well for 1 to 15 engineers | Pays off with many independent teams |
| Infrastructure cost | Low, one environment | Higher, orchestration and service mesh overhead |
| Data consistency | Simple transactions | Eventual consistency, distributed transactions |
| Best fit | 99% of businesses | Netflix-scale organizations with a real scaling or team problem |
Key Takeaways
- Microservices solve an organizational problem, not a technical one. If your team doesn't have that problem, the pattern doesn't help you, it just adds moving parts.
- The monolith is not a stepping stone to be embarrassed by. Clean internal module boundaries mean you can split it apart later, only when the pain justifies it.
- Every network call, deploy pipeline, and consistency headache you avoid by staying monolithic is real velocity and real budget you get to keep.
Frequently Asked Questions
Do I need microservices if I'm using Kubernetes?
No. Kubernetes is a deployment and orchestration tool, not an architecture. You can run a single monolithic container on Kubernetes and get its scaling and reliability features without the operational overhead of splitting the application apart. Kubernetes doesn't settle the microservices vs monolith question, the two are orthogonal.
When should a small team actually consider microservices?
When you can point to a specific, current pain: one component needs wildly different scaling than the rest, or multiple teams are actively blocking each other on deploys. "We might need this eventually" is speculation, not a current pain, and speculation is expensive to build for.
Can a monolith really scale to millions of users?
Further than most people assume. Stack Overflow ran on a handful of servers well past Fortune 500 traffic levels. Vertical scaling (a bigger server) and a couple of read replicas cover a lot more ground than the "monoliths don't scale" myth suggests. In the microservices vs monolith trade-off, raw scalability is rarely the actual bottleneck for most businesses.
What is a modular monolith, and is it a real alternative?
Yes, and it's often the best of both worlds. You build the application as a single deployable unit but enforce clean internal boundaries between domains (billing, users, inventory) in code. If a module later genuinely needs to become its own service, you extract it along a boundary you already understand, instead of guessing where to cut a system that was never organized that way.
How do I know when it's actually time to split a monolith into services?
When you can name the exact bottleneck: a specific team that can't deploy independently, a specific component with a scaling profile the rest of the system doesn't share, or a specific compliance boundary that needs its own deployment lifecycle. If you can't name it precisely, it's not time yet.
Mantrax builds and modernizes custom software for businesses that need working systems, not architecture trophies. If your "microservices" have become the problem instead of the solution, let's talk.
