The Pendulum Has Swung
In 2015-2020, microservices were the answer to everything. Every startup decomposed their monolith. Kubernetes became the default deployment target. Service mesh proliferated.
In 2023-2025, major companies are publishing case studies about moving back to simpler architectures:
- Amazon Prime Video moved from microservices to a monolith for their monitoring service: cut infrastructure costs 90%, reduced complexity "dramatically"
- Stack Overflow serves ~2 billion page views/month from 9 on-premise servers running a monolith
- Basecamp has run a 40M+ user product as a Rails monolith for 20 years
- Shopify operates as a "modular monolith" — one deployed artifact but well-separated internal boundaries
The lesson isn't that microservices are bad. It's that they solve specific organizational and scaling problems that many teams don't actually have.
The Real Cost of Kubernetes at Different Scales
Small team (2-8 engineers), startup:
Running 12 microservices on EKS:
- EKS control plane: $73/month
- Worker nodes (3x t3.medium): $90/month
- ALB load balancer: $25/month
- NAT gateway: $35/month
- 2 DevOps engineer hours/week (at $100/hr): $800/month
- Datadog monitoring: $200/month
- Total: ~$1,223/month
Same workload on a monolith (single t3.xlarge + RDS):
- t3.xlarge: $120/month
- RDS db.t3.medium: $65/month
- Total: $185/month
Microservices cost 6.6x more for identical workload at small scale, and this ignores:
- 2-3 weeks of engineering time to set up CI/CD per service
- Distributed tracing and observability across services
- Network latency between services (every service call is now a network round trip)
- Service-to-service authentication overhead
Mid-size team (15-40 engineers), established product:
Running 40 microservices:
- EKS + 6 worker nodes: $380/month
- Service mesh (Istio): additional 15% compute overhead
- Monitoring/tracing (Datadog): $1,500/month
- 3 Platform engineers at $180K/year: $45,000/month
- Total: ~$47,000/month
Comparable monolith (2x r5.xlarge + RDS):
- Compute: $450/month
- RDS: $180/month
- Platform overhead (1 DevOps, 20% time): $3,000/month
- Total: ~$3,630/month
The operational cost difference at mid-scale: 13x.
When Microservices Are Actually Worth It
Microservices make economic sense when:
1. Conway's Law demands it. If you have 8 independent teams owning different product domains, and they need to deploy independently without coordination, microservices enable team autonomy. The coordination cost of shared monolith exceeds the operational cost of services.
2. Scaling profiles diverge significantly. If your image processing service needs 100 GPU instances on demand while your API needs 4 instances steady-state, a monolith forces you to either over-provision or build the scaling separation anyway.
3. Technology heterogeneity is required. ML inference in Python, real-time streaming in Go, CRUD API in TypeScript — legitimate technical reasons sometimes require separate deployment units.
4. Regulatory isolation. Payment processing may need to be isolated from the rest of your codebase for PCI compliance. Healthcare data may need HIPAA-isolated infrastructure.
What's not a sufficient reason:
- "It's more scalable" (monoliths scale surprisingly far; Instagram served 1B users with mostly Python monolith pre-acquisition)
- "It's more modern" (not an engineering criterion)
- "Netflix does it" (Netflix has 2,000+ engineers managing their service mesh; you have 12)
The Modular Monolith: The Best of Both
The pattern that's gaining adoption: a single deployable artifact with strong internal modularity.
In Rails: engines and the Packwerk gem enforce module boundaries without deployment separation. In Node.js: separate npm workspaces within a monorepo, deployed together. In Java: modules with explicit public API boundaries.
Shopify built this with Packwerk — 20 million lines of Ruby with clear package boundaries, zero inter-package test dependencies, enforced via CI. The result: independent team ownership, no runtime service overhead, no distributed systems complexity.
How to modularize a monolith:
- Define bounded contexts (domain areas that can own their data)
- Enforce boundaries through package/module restrictions (no direct database access across contexts)
- Communicate through well-defined internal APIs (methods, events), not shared database tables
- Extract services only when you have a real operational need (scaling, tech stack, regulatory)
The Real Microservices ROI Case
Microservices deliver positive ROI at:
- 50+ engineers with clear domain ownership
- Proven product-market fit with stable service boundaries
- Specialized scaling needs that require different infrastructure per service
- Organizational readiness for distributed systems complexity (on-call, observability, service mesh)
A rough framework: if you have fewer than 30 engineers and your product isn't at $10M+ ARR with proven scale requirements, a well-structured monolith will outperform microservices on cost, velocity, and reliability.
The irony: the companies that benefit most from microservices (large, complex, multi-team organizations) have the resources to absorb the operational overhead. Small teams that adopt microservices prematurely spend their limited DevOps budget on plumbing instead of product.
The Migration Path When You Do Need It
If you reach the scale where microservices make sense, use the Strangler Fig pattern:
- Identify the bounded context with the most independent scaling need
- Extract it as a service behind an internal API facade
- Route traffic gradually (canary deployment: 1% → 10% → 50% → 100%)
- Delete the old code after stability is proven
- Repeat for the next candidate
Never big-bang rewrite. Every successful large-scale microservices migration happened incrementally over 2-5 years.
Use our Microservices Cost Calculator to compare infrastructure costs for your specific team size and workload.