Don't microservice, do module

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.