Are Microservices a Nightmare for Small Teams?

01 | Alibaba and Tencent Success Unrelated to Microservices

Many people treat microservices as a silver bullet, but the first Alibaba and Tencent double‑11 sales in 2009 occurred before microservices existed, and major companies like Alibaba, Tencent, Google, and Microsoft grew during periods when microservices were not present.

A company's success is driven by product value, not technology; microservices contribute at most 5% and are at best a garnish, not a rescue.

"Microservices are just a branch of SOA, inheriting its core ideas. SOA peaked alongside ERP software, unnoticed by the public. Microservices emerged during the internet boom, leading many to mistakenly credit internet company success to microservices."

This reflects classic survivor bias.

02 | Debunking Microservice Myths

🔴 Myth 1: Microservices Reduce Complexity

While "separation of concerns" is a software engineering axiom, it means keeping interfaces between unrelated code as simple as possible.

In a monolith, module A calls module B via an in‑memory function call (nanoseconds). After splitting into microservices, the call becomes a network request involving serialization, transmission, and deserialization, turning nanoseconds into milliseconds—a 1,000× performance drop.

Serialization (object→JSON) → Network transfer (gateway, switch, load balancer) → Deserialization (JSON→object)

A 10‑person team with a 10 k daily‑active‑user e‑commerce system split into 15 microservices later reverted to a monolith because both operations and DevOps teams struggled with the added complexity.

Microservices do not lower complexity; they shift it from code to the network.

🔴 Myth 2: Microservices Speed Up Development

On the surface, each team focusing on its own service seems convenient, but most new features require patches across multiple services.

Implementing a simple "add pagination" feature often involves:

Developing in more than two services simultaneously

Coordinating teams with different priorities and capabilities

Editing code in multiple repositories

Manually launching several containers for testing

Deciding where unit tests belong (repo A or B)

Even Uber's original microservice diagram was simple, yet its engineers later admitted they did not fully understand how it worked; this is the norm.

"Once you adopt microservices, every technical decision becomes tied to it. Adding a new feature often means launching a new service, and the architecture diagram quickly balloons into a dense mesh."

🔴 Myth 3: Independent Deployment Increases Safety

The claim that a failing service is invisible to users sounds appealing, but it assumes the remaining services can tolerate any other service disappearing at any time.

Implementing Netflix's Chaos Monkey to test such resilience requires massive engineering effort that most companies cannot afford.

In practice, deploying multiple services leads to version mismatches, staggered releases, and complex traffic‑shifting strategies, each demanding extra engineering resources.

Handling one failing service is far easier than handling ten simultaneously.

🔴 Myth 4: Separate Scaling Is More Cost‑Effective

While per‑service scaling sounds efficient, for most applications horizontal scaling of a monolith is sufficient.

Only when a codebase contains truly parallel compute blocks whose data‑transfer cost is negligible compared to computation does separate scaling make sense; otherwise, network overhead outweighs benefits.

03 | When Are Microservices Actually Useful?

They are useful, but only for roughly 20% of scenarios.

80% Monolith + 20% Microservices

Modules with high reuse—user management, payment, permission—are candidates for micro‑serviceization, typically not exceeding 20% of the system; many enterprise apps stay below 10%.

Other modules should remain as they are.

04 | The Real Costs of Microservices

Development effort: monolith 1×, microservices 3–5×

Testing effort: monolith 1×, microservices 5–10×

Deployment effort: monolith 1×, microservices 3–5×

Operations effort: monolith 1×, microservices 5–10×

Collaboration cost: monolith low, microservices exponential growth

Fault diagnosis: single‑service failure vs. distributed cascade failures

Service‑level failures can trigger a cascade: Service A fails → retries increase load → Service B exhausts resources → Service B fails → subsequent services C, D, E also collapse.

Service A unavailable → retry traffic spikes → Service B exhausted → Service B unavailable → Services C, D, E cascade failure

Mitigating this requires timeout, retry, rate‑limit, fallback, circuit‑breaker, on‑call rotation, and change‑management—a full reliability stack, not just adding Spring Cloud.

05 | How to Choose

Simple recommendations:

Team < 20 people → stick with a monolith

Daily active users < 100 k → horizontal scaling of a monolith is enough

Rapid MVP iteration → avoid microservices; speed matters more than architecture

High‑reuse public modules → consider micro‑serviceizing the ~20% that repeats

Team > 50 people with million‑scale DAU → microservices can be considered

Conclusion

Microservices are not a scam, but they have been heavily over‑marketed, especially in China, turning into a KPI‑driven hype rather than a genuine architectural solution.

Amazon originally promoted microservices to enable independent development teams, not merely to push a specific stack.