Does your startup need complex cloud infrastructure?

Original Article ↗ Hacker News Discussion ↗

Many engineers argue that early-stage startups rarely need Kubernetes, microservices, or sprawling “cloud‑native” stacks, and would be better served by a simple monolith on a single VM or modest container setup. Commenters highlight how resume‑driven and hype‑driven architectures waste time and money, hurt developer velocity, and solve scaling problems most products never reach, while a boring stack (e.g., one server plus a managed database) can carry you surprisingly far. Others note that more complex, managed cloud services are justified when you have strict compliance needs or rapid growth, but recommend treating them as an incremental step once product‑market fit and real operational pressures exist.

Overall stance on complexity

  • Strong recurring view: most early-stage startups don’t need complex cloud architectures (K8s, heavy microservices, elaborate serverless).
  • Complexity is often driven by hype, resumes, or “we’ll need it at Google scale” dreams rather than real load or product needs.
  • Several argue: if you ever reach scale where you truly need that complexity, you’ll have money and time to rebuild.

Monoliths, single servers, and “boring tech”

  • Many report success with:
    • Single VPS or bare‑metal server (often Hetzner/DO) running a monolith.
    • Simple stacks: Rails/Django/FastAPI/Node, Postgres/MySQL/SQLite, Nginx/Caddy, maybe Redis.
    • Deployment via bash scripts, docker-compose, or tools like Kamal, Dokku, CapRover.
  • Modular monolith + clear API boundary is favored: easy to split later, but simple to run now.
  • Emphasis on UX and product‑market fit over architecture purity.

Arguments for managed cloud and Kubernetes

  • Others prefer managed services (RDS/Cloud SQL, managed Redis/Elasticsearch, GKE/EKS/Fargate) for:
    • Self‑healing behavior, autoscaling, backups, monitoring, and less on‑call pain.
    • Standard tooling that new hires already know, versus bespoke scripts.
  • Pro‑K8s commenters argue a small, well‑understood subset (deployments, services, ingress, Helm) on a managed cluster or k3s can be simpler long‑term than piles of ad‑hoc VM tooling.
  • Counterpoint: many first‑time K8s setups become brittle, over‑engineered “cloud native” mazes that are hard to debug and rewrite.

Serverless vs containers/VMs

  • Lambda/Cloud Functions praised for isolation, autoscaling, and not paying for idle, but criticized for:
    • Debugging/logging pain (CloudWatch), IAM sprawl, and proliferation of tiny functions.
  • Some advocate a middle ground: a few larger Lambdas or simple container services instead of dozens of functions.

Cost, scaling, and TCO

  • Repeated claim: raw cloud compute (EC2, Fargate) is much pricier than VPS/bare metal; many workloads fit comfortably on a single cheap box.
  • Others note developer time dominates cost; paying for managed infra can be cheaper overall and safer (especially under compliance regimes).
  • Several anecdotes of “cloud‑native” rewrites that lowered infra spend but greatly increased headcount and complexity.

Security, compliance, and data

  • For highly regulated domains (e.g., healthcare), some see managed cloud (audit, encryption, HIPAA‑aligned services) as almost mandatory.
  • Others say compliant self‑hosting is feasible with careful encryption, TLS, and process, but acknowledge it’s tedious and risky.