Microservices are dead? Why BigTech moves to Monolith | WAWTech 2025

Summary (technological concepts + product/ops takeaways)

The video argues that the “microservices are the future” wave (popular roughly 2014–2018) is reversing in 2025 as BigTech reconsiders—or reverts back toward—monolith-style architectures. The speaker frames this as a tradeoff:

• Microservices can increase architectural flexibility.
• But they also introduce substantial operational, engineering, cost, and incident-management complexity—especially at scale.

---

1) BigTech examples of microservices backlash / monolith re-adoption

The speaker cites public statements/articles suggesting microservices caused major problems (e.g., slowness, cost, operational complexity)—while emphasizing they aren’t intrinsically bad.

• Shopify: Reportedly faced customer/infrastructure slowness and increasing costs after heavy microservices adoption, allegedly costing “millions” and contributing to broken expectations.
• Basecamp: Says it’s proud to be monolithic again, claiming microservices nearly killed the business.
• Segment: Quoted sentiment like “microservices almost almost killed us.”
• Google Cloud: Acknowledges microservices may not be bad, but managing many services is complex.
• Oracle: Used as the speaker’s internal experience of microservices operational pain at larger deployment scale.

---

2) “Microservices scale problem”: service count → engineering and operational explosion

A core illustration uses Uber as an extreme example:

• ~4,000+ microservices
• Correspondingly large engineering/task overhead

The implied idea: each microservice becomes an ownership unit, which makes management harder as service counts grow.

Core claim: copying this pattern blindly is dangerous—microservices add a structural complexity tax.

---

3) Speaker’s case study: Oracle’s shift from monolith to microservices, then operational pain

The speaker (Alex, working at Oracle) describes a transition.

Before microservices (initial state)

• Monolithic product
• ~4 data centers
• Weekly/daily releases (simpler deployment targets)
• Faster incident resolution and easier rollbacks

During the microservices shift

• Around 2018:
  • Increased data centers to 16
  • Introduced private clouds
  • Split the product into ~a dozen (~12) microservices, manageable at first:
    • Easier monitoring/telemetry
    • Clear redeploy/rollback behavior
    • Fewer deployment targets and fewer versions in parallel

“Today” (as described by the speaker)

• Oracle cloud infrastructure expanded to ~51 data centers (plus private clouds)
• Microservices allegedly grew toward ~50–70
• Deployment complexity explodes due to “many services × many data centers,” reaching “3,500 deployments” scale (speaker mention)

Resulting operational nightmare

• The deployment pipeline becomes a “nightmare” for:
  • rollout/rollback
  • investigation
• Complexity is described as increasing exponentially with:
  • number of microservices
  • number of deployment points

---

4) Incident response example: microservices make debugging + rollback harder

The speaker describes an incident-management cycle:

• An SR/incident manager wakes engineers at night (example: 1:00 a.m., Friday)
• Debugging requires repeatedly:
  • tracking down developers
  • ruling out services
• Issues may be hard/impossible to reproduce locally
• Rollback becomes complex:
  • With thousands of deployments in the last 24 hours, choosing what to roll back is difficult
  • Dependencies mean rolling back one service may break others due to version compatibility

Claimed impact:

• Microservices: incident resolution may take ~60–120 minutes up to ~4 hours
• Monolith: rollback can be “press the button” style—uploading a single code bundle

---

5) Cost impact: infra duplication + slower recovery + more work per change

The speaker argues microservices raise costs due to:

• Running old + new deployments in parallel during migration (e.g., traffic splitting/agents)
• Slower MTTR-like outcomes:
  • monolith rollback/restore: ~35 minutes
  • microservices rollback/troubleshooting: ~4 hours
• Deployment complexity:
  • monolith deploy upload: ~6 minutes
  • microservices with canary/multi-service waiting: ~38 minutes (framed as an order-of-magnitude jump)
• Additional log/observability overhead and related storage/processing costs

---

6) Operations/SRE overhead: dashboards, alerts, runbooks, and negotiation burden

A major operational point is coordination overhead:

• Microservices require building dashboards, alerts, and on-call procedures
• Alerts must be actionable so SRE knows what to do (runbooks/escalation paths)
• Negotiation burden:
  • engineers want SRE paged for precise conditions
  • SRE wants predictable, sleep-friendly paging schedules
• This multiplies across many services

---

7) Performance/latency overhead from splitting services and networking protocols

Another technical argument:

• In a monolith, intra-module calls are fast (same process/memory).
• In microservices, communication typically goes over:
  • HTTP
  • HTTPS/security policies
• The speaker claims significant overhead (including “4×” and “8×” figures tied to transmission/throughput effects).

Result (as described):

• Customers see slower event processing
• Teams then scale up (more servers, more traffic agents) just to restore baseline performance

---

8) “Checklist” recap: when microservices are not worth it

The speaker ends with a decision framework:

• If you have < 50 microservices, you likely don’t need them.
• If the service doesn’t truly require scalability (e.g., manageable with a simple VM/setup), consider a monolith.
• If you lack infrastructure expertise, microservices are risky—even strong teams may need years to “learn how to cook it.”
• If you want to “live without stress,” stick with monolith (without claiming microservices are universally bad).

---

9) Development and engineering tax: logging, tracing, security, testing, documentation, contracts

Additional complexity drivers include:

• Logs
  • Many services produce many logs
  • Example claim: 1 service → 1 log stream; 70 services → ~70 log streams
  • This increases aggregation/storage/processing needs.
• Tracing/diagnostics
  • Requires cross-service trace correlation when moving from service A to B
• Security scanning
  • Monolith: CVE fixes can be handled in one release
  • Microservices: updating and releasing many services plus repeated scanning/approval
• Contracts/documentation
  • More documentation per service (deploy parameters, capacity assumptions, etc.)
• API compatibility
  • One service changing an API can break dependents
  • Requires more integration/pact-like tests
• Testing explosion
  • Integration coverage needs grow quickly; speaker claims it becomes quadratic
  • Full coverage becomes hard/impossible

---

10) Closing argument: beware “copying Netflix/Uber” without understanding why

Final guidance:

• Don’t adopt microservices just because famous companies did.
• Ask whether microservices are a real necessity or driven by hype.
• Evaluate whether your requirements genuinely demand that architecture.

---

Main speakers / sources (as stated)

• Speaker: Alex Gitzeno (also referred to as Alexander), Oracle engineer/manager
• Company sources referenced via quotes/articles: Shopify, Basecamp, Segment, Google Cloud, Oracle
• Example also includes: Uber