Why Most Companies Shouldn't Use Microservices

Q: How much do microservices cost compared to a monolith?

Real numbers from my enterprise projects: (1) Engineering costs: 3-5x more people needed. Monolith needs 2 devs + 0.5 ops. Microservices (20 services) need 8 devs + 3 SRE + 1 architect. (2) Infrastructure costs: 200-300% more. Monolith: 5 VMs (~$2K/month). Microservices: 40 containers + Kubernetes + service mesh + monitoring stack (~$8K/month). (3) Development time: 40-60% slower for cross-cutting features. Adding a feature in monolith: 1 sprint. In microservices: 2-3 sprints (coordination, backward compatibility, deployment). (4) Debugging: 5-10x longer. Simple bug in monolith: 30 minutes. In microservices: 4 hours (correlating logs across 8 services, suspected race conditions). ROI example: company migrating from monolith to microservices: cost $500K, 9 months work, velocity dropped 40% for 6 months. Goal: 'prepare for scale'. Reality: served 1,000 users (monolith would scale to 100K).

Q: What is a modular monolith and why is it better?

A modular monolith combines the operational simplicity of a monolith with the architectural benefits of microservices. Structure: (1) One deployment unit, but strongly separated internal modules, (2) Each module has its own database/schema (logical separation), (3) Communication through defined interfaces (like APIs, but in-process), (4) Ability to later extract modules to microservices (incremental migration). Benefits: Deployment simplicity (one process, one rollback), Easy debugging (one stack trace, no distributed tracing), ACID transactions work (no Saga patterns), Cross-module refactoring is easy (IDE refactoring, not breaking changes), Lower infrastructure costs (1 DB, 5 VMs instead of 40 containers). Example: Shopify serves millions of stores on a modular monolith. Stack Overflow serves 200M users/month on a few monoliths. GitHub operated on a monolith until 2019 (at 10M+ users). Strategy: Start with modular monolith, Monitor scalability metrics, Extract to microservices ONLY when you hit limits (concrete: >10K requests/sec, >500ms p99 latency from contention).

Q: How to convince management/CTO NOT to use microservices?

Present a business case based on numbers: (1) Cost comparison: 'Microservices: $500K first 18 months (infrastructure + 5 additional engineers + productivity drop). Modular monolith: $150K (existing team, minimal additional infra). Difference: $350K savings.' (2) Velocity risk: 'Reference projects show 40% velocity drop for first 6-12 months during migration. That delays roadmap by 2 quarters.' (3) Operational complexity: 'Current team is 6 devs + 1 ops. Microservices require 3 additional SREs (cost $450K/year) + on-call rotations (team burnout).' (4) Alternative proposal: 'Instead: Build modular monolith now ($150K, 3 months). Monitor scalability metrics. If we hit real limits (concrete: latency >500ms, throughput >10K req/s), migrate incrementally only bottlenecks.' (5) Risk framing: 'Netflix needed microservices at 200M users. We have 50K users. We're solving problems we don't have - and ignoring real problems (product-market fit, customer features).' Case study: 'Segment.com rewrote from microservices BACK to monolith in 2020. Result: 10x infrastructure cost reduction, 50% faster feature delivery. Post: https://segment.com/blog/goodbye-microservices/'

Q: When do microservices make sense?

Microservices are justified in specific, measurable scenarios: (1) Technical scale: You serve >10,000 requests/second PER function, Single monolith has >500ms p99 latency from contention, You have concrete bottlenecks confirmed by profiling (not assumptions). (2) Organizational scale: >50-100 engineers working on one codebase, Teams block each other on deployments (>10 deployments/day), Code review exceeds 3 days due to change size. (3) Technology diversity (business-justified): You need machine learning in Python, real-time analytics in Go, core business in C# (different runtime requirements), Third-party integration requiring security isolation. (4) Compliance/regulations: PCI DSS requirements demanding payment processing isolation, Compliance requiring independent audit/certification of individual components. Examples where it makes sense: Netflix (200M users, 1000+ engineers), Amazon (millions req/s, 10000+ engineers), Uber (extreme geo-distributed scale, thousands of devs). But note: even these companies started with monoliths and migrated only when they hit REAL limits.

Q: How to migrate from microservices back to a monolith?

Reverse migration is possible - key is incremental strategy: (1) Assessment and analysis: Map all microservices and their dependencies (dependency graph), Identify tightly coupled services (many inter-service calls), Measure costs: network latency, infra costs, developer time on coordination. (2) Grouping: Start with tightly coupled services (e.g., User + Auth + Permissions), Create 'bounded contexts' from service groups, Prioritize those with highest maintenance costs. (3) Migration strategy: Step 1: Consolidate databases (ETL to shared schema), Step 2: Merge services into one deployable unit (keeping separation of concerns inside), Step 3: Refactor inter-service calls to in-process calls, Step 4: Remove service mesh / network overhead. (4) Rollback plan: Maintain parallel deployments for 2-4 weeks, Feature flags for switching between old/new architecture, Comparative monitoring (latency, errors, costs). Case study Segment.com: Time: 4 months, Team: 3 engineers, Result: 10x cost reduction, 50% development acceleration. Instructions: https://segment.com/blog/goodbye-microservices/

"We're moving to microservices" - I heard this from a CTO of a company with 12 engineers and 5,000 users. Six months later: velocity dropped 60%, infrastructure costs increased 4x, the team spends 70% of time debugging network issues instead of building features. This isn't an exception - it's the norm. According to an O'Reilly report from 2020, 61% of companies implementing microservices report "significant operational difficulties," and 42% admit they "weren't prepared for the complexity."

I've worked on dozens of architecture projects - from startups to enterprise. I've seen companies lose millions on premature microservices migration. I've also seen companies scale to millions of users on modular monoliths. This truth is uncomfortable for the consulting industry, but most companies don't need microservices - and probably never will. This article shows why, with concrete numbers and alternatives.

01The Hype Trap: Netflix, Not Your Company

Every tech conference since 2015 showcases Netflix, Uber, Amazon case studies - companies with thousands of engineers and billions of requests. Problem: Your company is probably not at that scale. When discussing microservices vs monolith architecture, understanding scale context is crucial.

When Netflix Moved to Microservices

→

Scale: 200+ million users, 1000+ engineers

Realistically impossible for one team working on one codebase

→

Problem: Monolith couldn't handle >83 million req/day

Concrete, measured bottleneck - not theoretical

→

Process: 7+ years gradual migration with huge dedicated team

Not "big bang rewrite" - incremental evolution

→

Investment: Hundreds of engineer-years, custom tooling (Eureka, Hystrix, Ribbon)

Dedicated teams for platform engineering

Your Company (Probably)

Reality:

• 5-50 engineers
• 1,000 - 500,000 users
• 10-1000 req/second
• No dedicated platform team
• Budget: startups / mid-size enterprise

What Happens:

• 4 devs trying to manage 25 microservices
• Infra costs rise from $2K to $10K/month
• Debugging takes 60% of team time
• Velocity drops 40-60%
• Team burnout from on-call rotations

Key truth: Microservices solve SCALE problems that most companies will never experience. Meanwhile, they introduce operational costs from day 1.

Companies Succeeding with Monoliths

Shopify (2025)

Serves millions of stores and billions in annual transactions on a modular Ruby on Rails monolith. Why? "Operational simplicity allows us to ship features faster than competition."

Stack Overflow

200+ million monthly users, 6,000 requests/second on a few .NET monoliths. Team: ~25 engineers. Jeff Atwood: "The monolith allows us to keep a tiny, efficient team."

Basecamp (Hey.com)

Millions of users, Rails monolith. DHH: "The Majestic Monolith" - manifesto against unnecessary distribution. Zero scalability problems at their scale.

02Hidden Costs of Microservices: Real Numbers

Vendor pitches show benefits - independent deployments, technology freedom, failure isolation. Nobody talks about real costs. Here are concrete numbers from my enterprise projects. Similar to Kubernetes deployment, operational costs often exceed initial estimates by 200-300%.

1. Engineering Cost Explosion

Microservices require significantly larger teams for the same features:

Scenario: E-commerce SaaS Platform (50K users, 5M req/day)

MONOLITH - Required Team:
  4 Backend Developers:              $400K/year
  2 Frontend Developers:             $180K/year
  1 DevOps (part-time, 50%):         $80K/year
                            Total:   $660K/year

MICROSERVICES (20 services) - Required Team:
  8 Backend Developers:              $800K/year
  2 Frontend Developers:             $180K/year
  3 DevOps/SRE (full-time):          $480K/year
  1 Solutions Architect:             $200K/year
  1 Platform Engineer:               $180K/year
                            Total:   $1,840K/year

Difference:                          $1,180K/year (180% more)

Why more people?
  - Each microservice needs maintenance, monitoring, on-call
  - Cross-service features require coordination of multiple teams
  - DevOps complexity: CI/CD for 20 services vs 1
  - SRE dedicated to observability, incident response
  - Architect needed to manage inter-service contracts

Real case:

Fintech company (client 2024): migration from monolith to 18 microservices. Team grew from 12 to 28 engineers in 18 months. Cost: $2.4M additional salaries. Velocity: dropped 35% for first 9 months.

2. Operational Complexity Cost

Infrastructure, tools, and operations required for microservices:

Infrastructure costs comparison (Azure, production + staging):

MONOLITH:
  App Service (P2v3, 3 instances):     $600/month
  Azure SQL Database (S3):             $400/month
  Redis Cache (C1):                    $80/month
  Application Insights:                $50/month
  Azure DevOps pipelines:              $40/month
  Storage & CDN:                       $100/month
                              TOTAL:   $1,270/month ($15,240/year)

MICROSERVICES (20 services):
  AKS Cluster (3 nodes D4s_v3):        $800/month
  Additional nodes for HA (2):         $600/month
  Azure SQL (5 databases, S3 each):    $2,000/month
  CosmosDB (2 instances):              $800/month
  Redis Cache (C2, shared):            $160/month
  Service Bus Premium:                 $700/month
  API Management (Developer tier):     $50/month
  Application Insights (20 services):  $400/month
  Log Analytics (1TB/month):           $300/month
  Azure DevOps (20 pipelines):         $320/month
  Storage, CDN, networking:            $400/month
  Service Mesh (Istio/Linkerd):        $200/month
  Monitoring stack (Grafana Cloud):    $300/month
                              TOTAL:   $7,030/month ($84,360/year)

Difference:                            $69,120/year (453% more)

Additional SaaS tools required:
  Distributed tracing (Datadog APM):   $500/month
  Incident management (PagerDuty):     $200/month
  Service catalog (Backstage hosting): $150/month
                              Total:   $850/month ($10,200/year)

Total microservices infrastructure cost:  $94,560/year
Total monolith cost:                      $15,240/year

DIFFERENCE: $79,320/year (520% more)

Note:

This doesn't include engineering costs for maintaining this infrastructure (CI/CD, monitoring, scaling). Add another ~$150K/year in DevOps time.

3. Productivity Tax

Microservices introduce friction in every aspect of development:

Development time comparison - Real Feature: "Add email field to user profile"

MONOLITH (timeline: 2 days):
  Hour 1:    Add DB column, update model
  Hour 2-4:  Update API endpoints (3 places)
  Hour 5-6:  Add validation, unit tests
  Hour 7-8:  Update UI forms
  Hour 9-10: Integration tests, code review
  Hour 11:   Deploy to staging, QA
  Hour 12:   Deploy to production
  TOTAL: 12 working hours (1.5 days)

MICROSERVICES (timeline: 1.5 weeks):
  Day 1: Impact analysis (which services affected?)
    - User Service (source of truth)
    - Auth Service (uses email)
    - Notification Service (sends to email)
    - Analytics Service (groups by email)
    - Admin Dashboard Service (displays email)

  Day 2-3: Design change (4 services)
    - API contract updates (versioning strategy)
    - Backward compatibility plan
    - Migration strategy for existing data
    - Cross-team alignment meeting

  Day 4-5: Implementation (4 services in parallel)
    - User Service: DB schema, API v2, data migration
    - Auth Service: update token claims, v1 compatibility
    - Notification Service: new provider, fallback logic
    - Analytics Service: aggregation update, data backfill

  Day 6: Integration testing
    - Test entire flow across 4 services
    - Debugging distributed tracing
    - Network flakiness in tests

  Day 7: Deployment (4 services)
    - Deploy each service separately
    - Coordination: which order? (dependencies)
    - Rollback plan if something goes wrong
    - Monitor each deployment

  Day 8: Monitoring and incidents
    - Service Mesh timeout (unexpected latency)
    - Analytics backfill overloaded DB
    - Rollback Notification Service, fix, redeploy

  TOTAL: 60+ working hours (8 days) + coordination of 4 teams

DIFFERENCE: 5x longer for simple change

According to ThoughtWorks 2023 report:

Cross-service features in microservices take on average 3-6x longer than equivalent in monolith. This is the "distribution tax" - you pay it on every change.

4. Debugging Nightmare

Debugging in distributed systems is exponentially harder:

Scenario: "User can't place order" - debugging time

MONOLITH (average: 20-30 minutes):
  1. Check logs - everything in one place
  2. Stack trace shows exact problem
  3. Reproduce locally - entire flow in one process
  4. Debugger: breakpoint, inspect state
  5. Fix: change code, restart, test
  Time: 20 minutes

MICROSERVICES (average: 3-6 hours):
  1. Where's the problem? (8 services in flow)
     - API Gateway → Auth Service → User Service →
     - Cart Service → Inventory Service → Payment Service →
     - Order Service → Notification Service

  2. Correlate logs (30 min):
     - Find trace ID in first log
     - Correlate through 8 different log streams
     - Problem: one service didn't forward trace ID

  3. Discover issue (1 hour):
     - Timeout in Payment Service (but why?)
     - Check Payment Service logs: rate limiting from payment provider
     - But why suddenly rate limiting?

  4. Root cause (1.5 hours):
     - Inventory Service making 10x more payment checks than needed
     - Why? Bug introduced in deploy 3 days ago
     - Not caught because unit tests don't cover inter-service behavior

  5. Reproduction (1 hour):
     - Can't reproduce locally (8 services, databases, message queues)
     - Setup local Kubernetes (Docker Compose insufficient)
     - Or debug directly on staging (risky)

  6. Fix and verification (1 hour):
     - Fix in Inventory Service
     - Deployment
     - Verify entire flow through 8 services

  TOTAL: 5-6 hours + frustration

Additional complications:
  - Network issues (intermittent timeouts)
  - Race conditions (impossible to reproduce)
  - Distributed state inconsistency
  - Version mismatch between services

Google case study (2020):

"MTTR (Mean Time To Resolution) for incidents in distributed systems is 5-10x longer than in monoliths. Even with the best tools." - SRE Book, edition 2.

03Modular Monolith: Best Architecture for Most

There's a better solution: a modular monolith combines operational simplicity of a monolith with architectural benefits of microservices. In .NET migrations, we often recommend this architecture as the optimal solution.

What is a Modular Monolith?

A modular monolith is one deployment artifact with strongly separated internal modules. Imagine microservices... in one process.

Key Characteristics:

→ One deployment unit (one exe / Docker container)
→ Strong module boundaries (clear contracts, dependency rules)
→ Each module has its own database / schema
→ Communication through defined interfaces (like API, but in-process)
→ Ability to later extract module to microservice

Example Structure (.NET):

MyApp/
├── Modules/
│   ├── Users/
│   │   ├── Users.Core/          (domain logic)
│   │   ├── Users.Infrastructure/ (DB, external services)
│   │   └── Users.API/           (endpoints)
│   ├── Orders/
│   │   ├── Orders.Core/
│   │   ├── Orders.Infrastructure/
│   │   └── Orders.API/
│   ├── Payments/
│   │   └── ... (similar structure)
│   └── Notifications/
│       └── ...
├── Shared/
│   ├── SharedKernel/     (common types)
│   └── EventBus/         (inter-module events)
└── Host/                 (ASP.NET Core app)

Rules:
- Modules.Orders CANNOT reference Modules.Users.Core
- Communication only through: Events, APIs, Shared contracts
- Each module has own DbContext / schema
- Deployment: one process, all modules together

Benefits vs Microservices

✓Deployment simplicity: One artifact, one rollback
✓Debugging: Stack traces, local reproduce, one log
✓Transactions: ACID works, no Saga patterns needed
✓Performance: In-process calls (ns) vs network (ms)
✓Refactoring: IDE refactoring, not breaking changes
✓Infra costs: 5x lower (one DB, few VMs)

Preserved Microservices Benefits

✓Separation of concerns: Clear domain boundaries
✓Team ownership: Each team owns a module
✓Testability: Modules testable in isolation
✓Evolvability: Ability to refactor module
✓Migration path: Extract to microservice when needed

Example: Shopify Architecture (2025)

Shopify serves millions of stores, $200B+ GMV annually on a modular Rails monolith:

• ~400 "componentized sections" (modules) in one monolith
• Each module has clear boundaries, own tests, ownership
• Scale horizontally: 1000+ instances of the same monolith
• "Extracted services" only for extremes (fulfillment, payments at compliance boundaries)

Shopify's philosophy: "The monolith allows us to ship features faster than competition. That's our competitive advantage."

05Case Study: Segment.com Returned to Monolith

Segment.com, an analytics company serving billions of events, publicly documented their return from microservices to monolith in 2020. This is one of the best case studies showing the real costs of microservices.

Their Journey

2015-2017: Migration to Microservices

• Split monolith into 140+ microservices
• Goal: Better scalability, team independence
• Investment: 2 years, majority of engineering team

Problems They Encountered

• Infrastructure costs: $1.2M/month on AWS (mostly for idle resources)
• Operational complexity: "Every feature required changes in 5-10 services"
• Debugging nightmare: "Incidents took hours for root cause"
• Developer productivity: "3x longer time to ship features"

2020: Reverse Migration to Monolith

• Consolidated 140 microservices to 2 modular monoliths
• Time: 4 months, 3 engineers
• Strategy: Gradual consolidation of tightly coupled services

Results After Return

10x

Infrastructure cost reduction

$1.2M → $120K/month

50%

Faster delivery

Features in days, not weeks

80%

MTTR reduction

Debugging 5x faster

Their conclusion: "For most companies at our scale, a monolith is the better choice."

Key Lessons

1.Microservices aren't free lunch: You shift complexity from code to infrastructure and operations
2.Most companies overestimate their scale problems: Segment served billions of events on a monolith
3.Reverse migration is possible: If you made a mistake, you can undo it
4.Modular monolith gives most benefits: Separation of concerns without operational costs

06FAQ

When are microservices a bad choice?

Microservices are a bad choice for most startups and companies below 50-100 engineers. Avoid when: (1) you're in MVP/product-market fit phase - you need speed, not complexity, (2) you have <10 engineers - you don't have people for on-call rotations, (3) you don't have a dedicated DevOps team - who manages 50+ services?, (4) business domains are tightly coupled - every change requires changes across multiple services, (5) you haven't experienced scalability problems - you're solving problems you don't have. Instead: start with a modular monolith with clear domain boundaries.

How much do microservices cost compared to a monolith?

From my projects: (1) Engineering costs: 3-5x more people. Monolith: 2 devs + 0.5 ops. Microservices (20 services): 8 devs + 3 SRE + architect. (2) Infrastructure: 200-300% more. Monolith: $2K/m. Microservices: $8K/m. (3) Development time: 40-60% slower for cross-cutting features. (4) Debugging: 5-10x longer. ROI example: company migrating from monolith: cost $500K, 9 months, velocity dropped 40%. Goal: "prepare for scale". Reality: 1,000 users (monolith would scale to 100K).

What is a modular monolith and why is it better?

A modular monolith combines operational simplicity of a monolith with architectural benefits of microservices. Structure: one deployment unit, strongly separated internal modules, each with own DB/schema, communication through interfaces, extraction ability. Benefits: simple deployment (one rollback), easy debugging (one stack trace), ACID transactions, easy cross-module refactoring, 5x lower costs. Example: Shopify serves millions of stores, Stack Overflow 200M users/month, GitHub operated until 2019 (10M+ users) - all on monoliths. Strategy: start with modular monolith, monitor metrics, migrate ONLY when you hit limits (>10K req/s, >500ms p99).

How to convince management/CTO NOT to use microservices?

Business case based on numbers: (1) Costs: "Microservices: $500K in 18 months (infra + 5 engineers + productivity drop). Monolith: $150K. Savings: $350K." (2) Velocity risk: "40% drop for 6-12 months = roadmap delay by 2 quarters." (3) Complexity: "Current team: 6 devs + 1 ops. Microservices require 3 SREs ($450K/year) + on-call rotations (burnout)." (4) Alternative: "Build modular monolith ($150K, 3 months). Monitor. If we hit limits (latency >500ms, throughput >10K req/s), migrate incrementally." (5) Framing: "Netflix needed at 200M users. We have 50K. We're solving problems we don't have." Case: Segment.com rewrote BACK: 10x cost reduction, 50% faster delivery.

When do microservices make sense?

Justified in specific scenarios: (1) Technical scale: >10,000 req/s per function, monolith has >500ms p99 from contention, concrete bottlenecks confirmed by profiling. (2) Organizational scale: >50-100 engineers, >10 deployments/day (teams blocking), code review >3 days due to size. (3) Tech diversity (justified): ML in Python, real-time in Go, core in C# (different runtime), third-party integration requiring isolation. (4) Compliance: PCI DSS requiring payment isolation, independent component audits. Examples: Netflix (200M users, 1000+ engineers), Amazon (millions req/s, 10K+ devs), Uber (extreme geo-distributed scale). Note: even they started with monoliths and migrated at REAL limits.

How to migrate from microservices back to a monolith?

Reverse migration is possible - incremental strategy: (1) Assessment: map services and dependencies (dependency graph), identify tightly coupled (many inter-service calls), measure costs (latency, infra, developer time). (2) Grouping: start with tightly coupled (User + Auth + Permissions), create bounded contexts, prioritize highest maintenance costs. (3) Migration: Step 1: consolidate databases (ETL to shared schema), Step 2: merge to one deployable unit (keeping separation inside), Step 3: refactor inter-service calls to in-process, Step 4: remove service mesh overhead. (4) Rollback: parallel deployments 2-4 weeks, feature flags for switching, comparative monitoring. Case: Segment.com - 4 months, 3 engineers, result: 10x cost reduction, 50% acceleration.

Key Takeaways

→90% of companies don't have Netflix scale - microservices solve problems you'll probably never experience
→Real costs: 3-5x more engineers, 200-300% more infrastructure, 40-60% slower development
→Modular monolith gives most benefits without operational costs - Shopify, Stack Overflow, GitHub prove it works at scale
→Microservices make sense only with concrete, measured bottlenecks: >10K req/s, >100 engineers, compliance requirements
→If you prematurely implemented microservices - reverse migration is possible (case: Segment.com)
→Strategy: start with modular monolith, monitor metrics, migrate INCREMENTALLY only when you hit REAL limits

Need Help with Architecture Decisions?

I help companies choose the right architecture: microservices, monolith, or something in between. I assess existing systems, research bottlenecks, and recommend solutions based on data, not hype.

Request Architecture Review Read: Microservices vs Monolith 2025

Microservices vs Monolith 2025

Comprehensive guide to choosing architecture

Azure AKS in Production

Kubernetes deployment for enterprise applications

.NET Migration Guide

Migration from .NET Framework to .NET 10

Technical Debt Quantification

How to calculate debt cost for stakeholders