Why aren't we all serverless yet?

Original Article ↗ Hacker News Discussion ↗

Cost and Performance

  • Many argue serverless (especially AWS Lambda-style FaaS) is significantly more expensive than containers or VMs for sustained workloads.
  • Pricing is seen as a “billing model” layered on the same underlying compute, with each abstraction step (Lambda → Fargate → EC2) adding cost.
  • Several comments describe large cost savings from leaving serverless for monoliths/containers, while others report specific bursty workloads where switching to Lambda cut costs dramatically.
  • Serverless can be slower: cold starts, extra orchestration overhead, and time limits (e.g., ~15 minutes) hurt high‑compute or long‑running tasks like video transcoding.

Developer Experience and Complexity

  • Many find DevEx poor: YAML/IAM sprawl, CDK code exceeding app code, harder integration testing, weak local dev, painful debugging and observability.
  • Some like the “zero sysadmin” aspect and rapid deploys for small services, but others say the supposed simplicity disappears at scale.
  • Tooling like CDK, Amplify, SST, and cross-cloud abstractions are mentioned as partial mitigations, with mixed reviews.

Architecture Choices: Monolith vs Serverless

  • Strong sentiment that simple monoliths (often with established frameworks like Rails) are easier to reason about, debug, and cost-estimate.
  • Serverless architectures can devolve into “function explosion”: hundreds of Lambdas, many queues/topics, effectively a distributed monolith with high cognitive load.
  • Several argue you can design modular/microservice-like boundaries inside a monolith and avoid network-induced complexity.

Vendor Lock-In and Portability

  • Lack of standardized APIs and deep integration with cloud‑specific features creates lock‑in and migration pain.
  • Local reproduction of the production environment is often hard or impossible, pushing people to develop directly against the cloud.
  • Some mention emerging cross-provider frameworks, but they are niche.

Where Serverless Works Well

  • Commonly cited good fits:
    • Very low-traffic endpoints or cron-like jobs.
    • Highly bursty, short-lived CPU tasks where scaling to zero matters.
    • Background automations, glue code, notifications, or one-off bots.
  • Several say it’s reasonable for “toy” projects or side utilities, but fiscally unwise as the backbone of a high-scale product.

Terminology and Conceptual Debates

  • Extended debate over what “serverless” really means:
    • One camp: “someone else’s server / responsibility.”
    • Another: return to a CGI-like model where the app isn’t itself a long-lived server.
  • Many find the term misleading marketing; some see it as historically defensible but still confusing.