The microservices hype convinced an entire generation of developers that monoliths are legacy architecture. But here’s the uncomfortable truth: your team doesn’t need microservices. You think you do, but you don’t. You need a well-structured monolith. And the industry is quietly admitting it.
Amazon Moved Back to Monolith and Saved 90%
In 2023, Amazon Prime Video published a case study that sent shockwaves through the architecture community. They moved their video monitoring service from microservices back to a monolith and reduced costs by 90%. Not a typo. Ninety percent. The team that literally invented AWS—the cloud infrastructure powering half the internet—decided microservices were too complex and expensive for their use case.
If Amazon can’t justify microservices for a production system at scale, what makes you think your 10-person startup needs them?
The Premature Optimization Trap
Microservices solve real problems. Just not yours. Not yet, anyway.
You’re optimizing for Netflix-scale traffic before you have 100 daily users. You’re adding distributed tracing, service meshes, and eventual consistency complexity when you should be validating product-market fit. You’re wasting months configuring Kubernetes when your competitors with monoliths are shipping features.
The evidence is everywhere. Shopify serves millions of requests per second on a modular monolith. Stack Overflow handles billions of monthly page views with a monolith .NET application. 37signals runs Basecamp and Hey—products serving millions of users—on Ruby on Rails monoliths deployed by three-person teams.
Monoliths scale. The bottleneck isn’t your architecture. It’s not having enough users to warrant the complexity you’re adding.
The Real Cost Nobody Talks About
Microservices don’t just cost money. They cost developer velocity, and that’s far more expensive.
Every feature now requires coordinating across five services. Debugging moves from reading stack traces to distributed tracing across ten systems. Running the app locally means spinning up half a dozen databases and message queues. “Independent deployment” turns into careful coordination because services still depend on each other.
Ask developers who’ve lived through microservices migrations. The stories are consistent: “We spent six months setting up infrastructure before writing business logic.” “Debugging went from two hours to two days.” “Our microservices are just monoliths with network calls and 10x the latency.”
Your competitors aren’t dealing with this. They’re shipping.
Even the Experts Say Monolith First
This isn’t fringe opinion. The people who invented and popularized microservices are telling you to start with a monolith.
Martin Fowler’s “Monolith First” article, published years ago, concluded that almost all successful microservices stories started with a monolith that got too big. DHH has been evangelizing the “Majestic Monolith” for years at 37signals. Even Kelsey Hightower, a Kubernetes advocate at Google, admits most companies don’t need K8s and shouldn’t build like Google.
Sam Newman literally wrote the book on microservices. His recommendation? Only use them if you have specific problems they solve.
The only people still pushing microservices-first are consultants selling microservices migrations and developers building resumes.
When You Actually Need Microservices
Microservices aren’t wrong. They’re just premature for most teams. Here’s when you actually need them—all criteria must be true:
Team size exceeds 100 engineers. Conway’s Law becomes real at scale. Independent teams need independent services. Before that, you’re adding distributed systems complexity without the organizational benefit.
You have proven scalability bottlenecks. Not assumptions. Data. Specific services that need different scaling characteristics. If you don’t have metrics showing the problem, you don’t have the problem.
You have clear business domain boundaries. Splitting on technical lines fails. You need services that align with how the business actually works. Most companies discover these boundaries only after building the system.
You can afford the operational overhead. Microservices require dedicated SRE teams, sophisticated monitoring, service meshes, and distributed systems expertise. If you’re debating whether you can afford it, you can’t.
Ninety-five percent of companies fail at least one of these criteria. Most never reach these thresholds. And that’s fine.
Build a Monolith. Split When Necessary.
The path forward isn’t complicated. Start with a well-structured monolith. Build clear module boundaries. Use feature flags for independence. Monitor for actual bottlenecks. Extract services only when data proves necessity.
Most companies never reach that point. The ones that do—like Amazon Prime Video—now have the knowledge to split intelligently instead of following architecture trends.
Your team doesn’t need microservices. You need to ship features, validate ideas, and serve customers. A good monolith does that. Microservices do not.
Stop cargo-culting Netflix’s architecture and start building software that works.
