Why Microservices May Be Overhyped: Tracing Their Real Roots and Myths

1. Claimed benefits of microservices

Scalability – code can be split into smaller, independently developed units.

Focus – developers can concentrate on business logic.

Availability – backend data remains accessible to all devices.

Simplicity – large enterprise applications become easier to build.

Responsiveness – distributed apps can handle changing loads.

Reliability – replicated server groups avoid single‑point failures.

2. Historical origins of the claims

These six statements are not new. Two stem from early microservice literature, two from 20‑year‑old Enterprise JavaBeans (EJB) papers, and the remaining two trace back to the 40‑year‑old Oracle Tuxedo transaction system.

3. Core technical reality – modularity

The essence of microservices is modularity. A module—called an assembly in .NET, a JAR in the JVM, a DLL on Windows, or a shared object (.so) on Unix—represents an independent, versioned unit of code that can be built, deployed and reused separately.

David Parnas’s classic 1971 paper On the Criteria To Be Used in Decomposing Systems into Modules defines the criteria for such decomposition: each module should have a well‑defined interface, hide its internal implementation, and be replaceable without affecting other modules. These criteria map directly onto many of the advertised microservice advantages.

4. Critical examination of each advertised benefit

Big‑data best practices – The Unix “pipeline” principle (one program does one thing well, output feeds the next program) has existed since the 1970s. Microservices merely re‑express this idea at a network level.

Ease of building and maintenance – Same Unix principle: small, isolated programs are easier to understand and test.

Higher code quality – Focusing on a small, isolated unit reduces cognitive load, a benefit already recognized in modular design.

Reduced cross‑team coordination – In practice microservices still rely on heavyweight protocols (SOAP, WSDL, gRPC) and do not eliminate integration complexity.

Real‑time processing – Publish/subscribe and event‑bus architectures pre‑date microservices; they are not exclusive to any particular deployment model.

Accelerated growth via reuse – Reuse of modular components has been promoted for decades across languages and frameworks.

Increased output (different data presentations) – Data formatting for various audiences is a generic concern, not a microservice‑specific advantage.

Easy lifecycle updates (A/B testing, model evaluation) – These techniques existed long before the term “microservice”.

Scalability – Traditional transaction middleware and mainframe systems already provided horizontal scaling.

Tool abundance – Every architectural wave is accompanied by a surge of tooling; the presence of many tools does not validate the architecture itself.

5. Distributed‑computing fallacies

Research from the 1980s (Peter Deutsch) and the 1994 paper “A Note on Distributed Computing” by Ann Wolrath and Jim Waldo highlighted three persistent fallacies: performance, reliability and scalability are hard to achieve in distributed systems, regardless of the architectural style.

When a monolithic application is split across network nodes, latency can increase by five to seven orders of magnitude, and the need for additional network hops introduces new failure modes. Even container‑orchestrated deployments (Docker Compose, Kubernetes) add protocol overhead and inter‑process latency, which can negate the theoretical benefits of isolation.

6. When (and when not) to adopt microservices

Assess whether the problem domain truly benefits from independently deployable units. If the only gain is clearer code organization, a traditional modular monolith may be sufficient.

Consider the operational cost: additional infrastructure, monitoring, version compatibility, and the need for full‑stack expertise across teams.

Evaluate existing modular mechanisms (OS‑level libraries, language packages, OSGi bundles, JARs, DLLs) before introducing network‑level services.

Ensure that teams have a shared understanding of module interfaces and versioning policies to avoid hidden coupling.

Remember that the real value lies in “clear organization” – independent, versioned code units that can be explained and reasoned about, not in the buzzword itself.

In short, microservices are an application of well‑known modular design principles to modern deployment environments. Their hype often obscures the fact that the underlying concepts have been practiced for over fifty years.

Code example

1.
我的私密学习小圈子，从0到1手撸企业实战项目~
2.
目前工资最高的几家外包公司汇总！（2025 最新版）
3.
为什么苹果不对 12306 购票抽成 30%？
4.
Spring Boot 3 + Netty 构建高并发即时通讯服务