Don't microservice, do module
Debate over microservices versus modular monoliths centers on when the complexity of distributed systems is justified. Many engineers argue that microservices mainly solve organizational and scaling problems at large companies, while imposing heavy costs—deployment overhead, debugging difficulty, cascading failures—on small to mid-sized teams that could instead rely on well-structured modules. Others counter that services bring real benefits such as independent deployments, partial availability, resource isolation, and clearer team boundaries, but emphasize that architecture should follow concrete needs rather than hype.
Overall Tone and Meta-Discussion
- Many criticize the article’s absolutist framing (“microservices are the wrong answer”), arguing that strong black‑and‑white takes usually signal shallow experience.
- Repeated theme: “it depends” – architecture should follow context, scale, org structure, and constraints, not ideology or hype.
- Several posters lament that nuanced positions are harder to communicate and sell internally than bold, simple prescriptions.
- Some find the post technically weak and ranty; others think it’s directionally right about overuse of microservices but poorly argued.
Microservices vs Modules / Monoliths
- Broad agreement that microservices are often misapplied, especially in small teams and early-stage products, where they add heavy operational overhead (testing, deployment, monitoring, debugging, k8s).
- Many prefer a “modular monolith” or “modulith”: strong internal boundaries, single deployable unit, possibly later split into services.
- Some point out that monoliths can still be partially available and composed of separate processes (workers, queues) without full microservice fragmentation.
Where Microservices Shine
- Organizational scaling: independent teams, independent deployments and rollbacks, clearer code ownership, isolation of secrets and APIs.
- Partial availability and fault isolation: non‑critical services can fail without taking down the user‑critical path.
- Resource isolation and cost control: scale or right‑size heavy or infrequent workloads (large file processing, GPU-heavy models) without overprovisioning everything.
- Polyglot teams and reusable services across applications.
Problems and Misuses
- Microservices often become “distributed monoliths” with tangled dependencies and cascade failures, harder to monitor and reason about.
- Many issues attributed to microservices are actually organizational: poor communication, cargo‑culting big‑company patterns, underqualified k8s/platform setups.
- Network boundaries increase latency and complexity; debugging cross‑service failures is harder than in-process code.
- Critics highlight questionable claims in the article (e.g., dismissing per‑service scaling, ignoring real benefits like partial failure tolerance).
Alternatives and Enforcement of Boundaries
- Several advocate tooling and process (linters, CODEOWNERS, architectural checks) to enforce module boundaries inside a monolith instead of relying on network separation.
- Hybrid models are suggested: single binary or monorepo with clear module boundaries that can be deployed as one process, a few services, or many microservices as needs grow.