Serverless

Serverless is not "no infrastructure" — it is infrastructure with the operational knobs replaced by a billing meter and a set of hard limits you don't control. The platform enforces statelessness, imposes concurrency ceilings, and charges per invocation. That's a genuine gift for bursty, event-driven work, and a genuine liability for steady, latency-sensitive, or long-running work.

The question is never "is serverless good" — it's whether your workload's shape matches the platform's enforced shape. Match the workload's traffic and duration profile to the platform's constraints before you match its convenience.

1. Treat statelessness as enforced, not optional

A function instance can be frozen, killed, or never reused between invocations. Anything written to local disk or held in memory across calls is not guaranteed to survive to the next one. This is the same principle as cloud-architecture's statelessness default, except here the platform enforces it for you instead of asking nicely — so design the function so a cold, stateless restart on every single call would still be correct.