Serverless computing / functions as a service (FaaS)
You upload a function, the platform runs it on demand and bills per call. Servers exist, but babysitting them is not your job.
See it
What it is
There are still servers; you just never meet them. You hand the platform a function, it starts an instance when nothing warm is free, routes requests to whatever instances exist, and bills you per invocation and per millisecond of compute rather than per hour of an idle box. AWS Lambda started it, and Vercel Functions, Netlify Functions, Cloudflare Workers, and Google Cloud Run are the flavors most builders touch. No OS patching, no capacity planning, no 3am 'the instance ran out of disk'.
Reach for it when traffic is spiky or unknown, when the work is request-shaped (an API route, a webhook receiver, an image resize), and when you would rather write code than run infrastructure. Reach for a long-lived container or VM instead when you need websockets held open for hours, a warm in-memory cache, GPU work, or jobs that run for many minutes.
The constraints that surprise people. A warm instance gets reused, often for many requests in a row and on several platforms for concurrent ones, so a module-level database client or cache usually does survive between calls. What you never get is a guarantee: the next request may land on a fresh instance, and the filesystem is ephemeral, so treat local state as a lucky optimization and never as storage. Instance count is also out of your hands, which is how a spike opens a database connection per instance and blows past a traditional Postgres connection limit unless a pooler sits in front. There is an execution timeout. And 'scales to zero' and 'cold start' are the same fact wearing two hats.
Ask AI for it
Target the platform this repository is already configured for (look for a Vercel, Netlify, AWS SAM or Serverless, or Wrangler config before writing anything) and convert this API endpoint using that platform's native handler signature, not a generic one. Read config from environment variables, and initialize the database client once at module scope behind a pooler so warm instances reuse it instead of reconnecting per request. Write nothing to local disk; use object storage. Return early on invalid input. Then set the timeout and the memory or concurrency controls using that provider's own knobs and names, and estimate monthly cost from measured invocation duration against that provider's published pricing rather than a cross-platform figure you made up. If more than one platform is configured, ask me which to target before generating code.