You want microservices, but do you need them?

Original Article ↗ Hacker News Discussion ↗

Overall sentiment

  • Many commenters say they don’t “want” microservices; they want simpler ways to structure and deploy systems (monoliths, SOA, “macro/mini/goldilocks services”).
  • Microservices are seen as over‑applied, culturally driven (ZIRP, resume‑driven development, hype), and often unnecessary for typical loads.

When microservices (or multiple services) do make sense

  • Distinct workloads or resources:
    • GPU/ML workloads, heavy reporting, or time‑series/OLAP/search engines needing different hardware or data stores.
    • Regulatory boundaries (PCI/HIPAA) or clearly separate business lines.
  • Organizational scale:
    • Many teams owning different domains, needing independent deployment cadences and blast‑radius limits.
  • Operational needs:
    • Separately patching high‑risk vs high‑velocity components.
    • Service‑oriented architectures with a few well‑bounded services (auth, data service, GPU worker, etc.).

Common failures / “distributed monoliths”

  • Multiple tiny services per engineer, arbitrary splitting by team rather than true domain boundaries.
  • Shared databases across “microservices” without proper APIs, leading to tight coupling and painful schema evolution.
  • Extreme fragmentation (e.g., gRPC services for trivial queries) and “one RPC per function” thinking.
  • Kubernetes + microservices stacks that collapse under modest load and add huge cognitive and operational overhead.

Databases and data modeling

  • Strong emphasis that “good software is downstream of good data modeling.”
  • Shared, uncontrolled databases are described as “global variables”; microservices at least forced some teams to improve DB hygiene.
  • Disagreement on DB-per-service:
    • Some like shared DB behind a well‑defined API.
    • Others argue true service ownership of a table avoids distributed‑monolith lockstep changes but sacrifices easy joins.

Infrastructure: Kubernetes vs simpler stacks

  • Many prefer Docker/Podman + Compose (sometimes with Terraform) for local dev and small deployments.
  • K8s is seen as worth it only for very large, fast‑scaling, multi‑machine environments with dedicated ops expertise.
  • Pain from maintaining separate local (Compose) and prod (K8s/Nomad) configurations is common.

Alternative architectures and tools

  • Strong interest in:
    • Modular monoliths and SOA; “miniservices” or “goldilocks services” sized around real domains or teams.
    • Single executables/uberjars or containers as the deployment unit.
    • BEAM (Erlang/Elixir) for “microservices inside a monolith” via lightweight processes.
    • WebAssembly modules as self‑contained components.
  • Some note AI tools handle smaller, focused services more easily; others say AI benefits from monolith‑level context.