Hello everyone! I’m Hung Pham, a backend developer who used to think that microservices were the standard for every system—until I actually deployed and maintained one myself. After many nights struggling with dozens of logs from 4–5 different services, I realized one thing: microservices aren’t the right solution for every system. Why? Let me share my story in detail, hoping it will give you a more realistic perspective on microservices.
1. In the beginning—microservices seemed like the “holy grail”
When I first discovered microservices, it felt incredibly exciting. The hype, the case studies from big players like Netflix, Amazon, Uber, and Google made me almost obsessed:
- “Break your app into small parts that can be developed and deployed independently, as you wish!”
- “Scale each service separately—no need to scale the whole bloated app!”
- “If you’re not doing microservices, you’re falling behind—it’s the future of software development!”
I dove straight into Docker, Kubernetes, service mesh, CI/CD automation, API Gateway… The list of things to learn was endless—longer than the actual project deadlines! I thought I was opening a brand-new chapter for my backend career.
2. But reality was not as dreamy
When I finally “microfied” some of my team’s projects—our small team had only 4–5 devs—I realized that microservices were not just about splitting up code. It’s a complex web that nearly drove me crazy:
- Network latency and timeouts: If a single service is slow, the whole system can crash like a line of dominos. One seemingly simple request might pass through a dozen services—timeouts and partial failures became routine.
- Complicated deployment management: Each service had its own CI/CD pipeline, its own configs, its own versioning. Deployments weren’t just a click anymore—they turned into a campaign.
- Data consistency headaches: No more simple transactions. Now we had to think about eventual consistency, complex patterns like Saga, Orchestrator (Camunda, Temporal…)—just hearing those words made me want to give up.
- Debug logs were a nightmare: When production issues hit, I had to dig through logs from multiple services, tracing requests across systems. I felt like Sherlock Holmes stumbling in the dark!
3. The things microservices “stole” from our small team
For our small team, I realized microservices were stealing many valuable things from us:
- Focus:
- Monolith: One repo, one codebase, everyone working together—easy to communicate, easy to grasp the big picture.
- Microservices: Everyone camping in their own service, talking only via APIs, creating silos in the team.
- Initial development speed:
- Monolith: Deploy once, rollback once, small changes went live quickly.
- Microservices: Deployments scattered across services, config tweaking everywhere, rollbacks were trickier and took much longer.
- The joy of releasing features:
- Monolith: Release a feature immediately, get instant feedback from users.
- Microservices: Release in pieces, carefully coordinate to avoid breaking APIs—stressful and slow.
4. But microservices aren’t the villain
I’m not denying that microservices have some real strengths:
- Independent scaling: Hot services can be scaled separately, saving resources.
- Empowered teams: Teams can work independently on their services, reducing dependencies and speeding up long-term development.
- Easy to evolve and replace: Updating a single part doesn’t require messing with a huge monolith.
5. So when should you actually use microservices?
I think microservices only truly shine when:
- Your project has a large backend team (10+ devs), so you can split by domain.
- Your infrastructure is mature enough (CI/CD automation, great observability—logging, tracing, metrics…), so deploying doesn’t feel like rocket science.
- Your application has clear, separate domains—like payments, user management, logistics, each operating almost independently.
- Your traffic is huge, and you really need to scale specific components to save costs and boost performance.
6. And when you probably shouldn’t “play fancy”
If you’re in one of these situations, think twice before jumping into microservices:
- Small team (3–5 devs), drowning in backlog with tons of features to build.
- Simple application with just a few main modules, no real need for complex scaling.
- No experience with CI/CD or DevOps—microservices will force you to learn DevOps first.
- Tight deadlines (like 1 month to launch) rather than a year for sustainable growth.
7. Conclusion: I don’t hate microservices—I just don’t like meaningless “hype-following”
Microservices aren’t evil. They’re not “automatically great,” either. I just don’t like when small teams chase trends blindly and burden themselves with unnecessary complexity.
For me, the most important thing is:
- Understand your actual problem.
- Choose the architecture that fits your team size, your app’s nature, and the real complexity you need.
In short:
- Small team, few features, tight deadlines: Monolith is king.
- Big team, complex domains, heavy traffic: Microservices is the savior.
8 And what about you?
Have you had a wildly successful microservices experience? Or a complete disaster? I’d love to hear your stories—so we can learn from each other and avoid repeating the same mistakes I did.
Top comments (2)
Very useful, tks bro
Sounds like a reasonable argument.