Stop Creating Microservices | Prime Reacts

Core thesis

Microservices became a mainstream solution through hype rather than consistent technical necessity. Many promised benefits are real but often misapplied; what teams usually need are well-designed modules, clear team boundaries, and good interfaces — not necessarily distributed microservices.

• The same selling points for microservices have appeared in earlier technologies (EJB, Tuxedo, SOA).
• In many cases, well-designed in-process modules or packaged units deliver the needed benefits with far less complexity.

Technological concepts & analysis

Claimed microservices benefits (and critiques)

• Scalability
  • Can isolate bottlenecks per component.
  • Introduces new network and coordination scaling costs and potential distributed bottlenecks.
• Independent deploy/test/update
  • Works for small services, but API changes, versioning, and client compatibility (especially long-lived/stale clients) create ongoing support burdens.
• Developer focus on business logic
  • Attractive in theory, but developers often spend significant time on integration, data formats, date/time normalization, and incidental plumbing.
• Reliability / no single point of failure
  • Requires substantial operational investment (replication, canarying, automated rollbacks) to realize in practice.
• Real-time processing / pub‑sub
  • Event streaming and pub/sub are possible, but these patterns do not require a microservices architecture — monoliths can participate equally.
• Reuse / data outputs / ML workflows
  • Modularization helps, but marketing language about reuse is often inflated and can encourage over-generalization.

Distributed systems costs

• Fallacies of distributed computing apply: network calls are much more expensive and failure-prone than in-process calls (higher latency and lower reliability).
• Running services on the same host (containers/VMs) reduces but does not eliminate inter-process/network overhead because of the virtual network stack.
• Observability and tracing are significantly harder at scale (request IDs, tracing across many services, and n+1 request problems).

Historical context

• Many microservices arguments echo older literature: Unix pipes, EJB critiques, Tuxedo/mainframe patterns.
• The core idea — independent, versioned modules with clear inputs/outputs — is decades old (see David Parnas, 1971).

Organizational drivers

• Amazon’s early microservices push emphasized team autonomy and reducing organizational blocking as much as technical architecture.
• Microservices often address organizational/coordination issues (team ownership, on-call responsibility) rather than purely technical problems.

Practical guidance / recommendations

Don’t default to distributed microservices

• Consider simpler alternatives first:
  • Well-defined modules inside a monolith (packages/assemblies).
  • Standalone processes hosted inside the same runtime or on the same host to reduce latency.
  • Serverless or simple service boundaries where appropriate.

If you move to microservices, prepare for operational complexity

• Invest in observability and tracing, canary and blue-green deployment automation, and standardized request IDs.
• Plan for API versioning and expect to maintain old endpoints for long-lived clients.
• Ensure teams have the necessary skills or dotted-line/matrixed support (DBA/infra/QA) so they aren’t blocked.

Organizational advice

• Create small cross-functional teams with clear autonomy, defined contracts, and a strong product/domain focus.
• Reduce external dependencies by bringing critical capabilities into the team’s “wheelhouse” where possible.

Tooling notes

• Containers: Docker, Docker Compose, Kubernetes — containerization does not remove inter-process/network costs.
• Protocols and formats: HTTP/JSON, gRPC, pub/sub/event streaming, message queues — choose carefully (binary vs text, IPC vs network).
• Big-data ecosystems: Hadoop, Spark, NoSQL, streaming analytics are commonly relevant.
• Languages/approaches: pick what matches the problem. Go monoliths were praised; Rust/Go and common languages (Python, .NET, Ruby, C++) are valid choices. Serverless can be appropriate in some cases.

Key warnings and pitfalls

• Replacing a single local library call with multiple networked service calls increases latency and reliability exposure; the slowest service sets the end-to-end pace.
• Microservices can create large amounts of ancillary work (deployment pipelines, testing harnesses, observability, on-call rotations) that distract from delivering business logic.
• The “reuse” argument is often overstated and can lead to over-generalized designs; sometimes smaller, simpler endpoints are better.

Notable references and historical sources cited

• Unix philosophy / pipes and filters (1970s).
• David Parnas — “Criteria to be Used in Decomposing Systems into Modules” (1971).
• Fallacies of distributed computing — Peter Deutsch; related work by Ann Wollrath & Jim Waldo (1994).
• EJB literature and Oracle Tuxedo / mainframe transactional middleware (historical precedents).
• Industry case studies: Amazon, Netflix.
• Commentary: Jonathan Blow (referenced remarks).

Main speakers and sources

• Prime (video host / commentator — “Prime Reacts”).
• Referenced primary materials: microservices literature and blog posts (including Netflix-style accounts), historical EJB/Tuxedo materials, David Parnas (1971), Peter Deutsch, Ann Wollrath & Jim Waldo (1994).