The Uptime Engineer
👋 Hi, I am Yoshik Karnawat
Don’t scroll past, this week’s 180 second read might just save you hours at work.
Facts About Microservices
Amazon ran on a monolith until 2001. Then spent years migrating to microservices with hundreds of engineers
Netflix operates over 1,000 microservices but started as a monolith and had 200+ engineers before the split
Microservices add 15-25% to infrastructure costs just for observability and monitoring tools
70% of startups that go microservices-first report slower feature velocity in the first 12 months
You've probably heard this one before.
"Microservices let you scale independently, deploy faster, and move like Netflix"
So you split your 3-person engineering team's app into 8 services.
Now you're debugging why payment can't talk to users.
And your deploys take 40 minutes instead of 5.
Here's the truth:
Microservices trade code complexity for operational complexity.
Unless you have the tooling, culture, and headcount to absorb that cost, you're paying in downtime and developer sanity.
Here's what "going microservices" actually means:
Network replaces function calls
Every request crosses process boundaries.
Network overhead reduces performance by 10-30%.
Observability becomes survival
Without distributed tracing, you can't debug anything.
Observability alone costs 15-25% of infrastructure budget.
Everything multiplies
Auth, logging, metrics, config each service needs it.
Teams spend 30-50% more time on deployment automation.
Data consistency becomes a nightmare
Eventual consistency adds 20-40% to development time.
Change one table, and 3 others silently break.
When monoliths win
You don't pick microservices for performance.
You pick them for team scaling when coordination overhead exceeds code coupling.
For teams under 20 engineers, monoliths win:
Aspect | Monolith | Microservices |
|---|---|---|
Deploy Speed | ✅ One pipeline | ❌ Multiple |
Debugging | ✅ Straightforward | ❌ Distributed tracing |
Resource Cost | ✅ Cheaper | ❌ Per-service overhead |
Early adopters of microservices face:
3-6 months defining service boundaries
40% budget overrun beyond implementation costs
Velocity drops instead of increases
The playbook
Start with a modular monolith logical separation without network separation.
Here's what works:
Build a clean monolith with clear domain boundaries
Automate tests + CI early
Extract services only when domains become independent
You can always split later but you can't easily merge back.
The principle
Microservices are an organizational scaling tool, not a technical milestone.
Amazon, Netflix, and Uber use them because they have hundreds of engineers and dedicated infrastructure teams.
You probably have 5 engineers and a Kubernetes cluster you barely understand.
Don't optimize for scale you don't have.
A boring, maintainable monolith gets you there faster than any trendy architecture ever will.