What you'll learn
Quick Answer
You upload a function and the provider runs it on demand, scaling automatically and billing per invocation. There is no server to manage, but functions are stateless, time-limited, and suffer a cold start on the first request after idling.
The model
Traditionally you provision a server, deploy code onto it, and it runs continuously waiting for requests. You pay for it whether it handles a million requests or none.
Serverless inverts this. You upload a function. When an event arrives — an HTTP request, a file upload, a scheduled timer, a queue message — the provider starts an execution environment, runs your function, returns the result, and may discard the environment.
Two consequences define everything else:
- You pay only for execution. No traffic means no bill. An API used twice a day costs almost nothing, where a virtual machine costs the same as one serving constantly.
- Scaling is automatic and immediate. A thousand simultaneous requests means a thousand concurrent executions, with no configuration and no load balancer.
The name is misleading — there are servers, and you are not responsible for any of them.
Cold starts
The most-discussed drawback, and worth understanding precisely rather than fearing.
If no environment is warm, the provider must create one: allocate a container, load your runtime, load your code, and run any initialisation. That delay before your handler even begins is the cold start.
How much it costs depends heavily on choices you control. Interpreted runtimes with small dependency trees start fastest; large bundles and heavyweight frameworks start slowest. A function importing a large SDK can spend most of its cold start on imports.
What reduces it: keeping the deployment package small, importing only what you need, moving initialisation such as database connections outside the handler so it is reused by warm invocations, and using provisioned concurrency where the platform offers it.
Whether it matters depends on the workload. For a background job nobody notices. For a user-facing API where a fraction of requests are slow, it is a real experience problem — and it is worst for low-traffic functions, because they are rarely warm.
The constraints that decide fit
These are not incidental limitations; they follow from the model.
- Stateless. Anything written to local disk or held in memory may vanish, because the next request may run elsewhere. All state goes to a database, cache or object store.
- Execution time limits. Functions are capped — typically minutes, not hours. Long processing must be split or moved elsewhere.
- No persistent connections. WebSockets and long-polling do not fit the request-response model directly and need a separate managed service.
- Database connections are a real problem. A thousand concurrent functions each opening a connection will exhaust a traditional database's connection limit. This surprises people, because the function layer scales beautifully and the database behind it does not. Connection pooling proxies exist specifically for this.
That last one is the most common serverless production incident, and it is worth mentioning in an interview because it shows you have thought past the marketing.
When it saves money and when it wastes it
The economics are genuinely different at different scales, and the crossover is real.
Serverless wins on spiky or unpredictable traffic, on low-volume workloads where a machine would sit idle, on event-driven processing such as resizing an uploaded image, and on scheduled jobs.
Serverless loses on steady high-volume traffic. A function invoked continuously at high rates costs considerably more than an equivalently-sized virtual machine, because you are paying a premium for elasticity you are not using.
Several companies have publicly moved workloads back off serverless for exactly this reason. That is not a failure of the model — it is the model behaving as designed once the workload stopped being spiky.
The other cost is operational: debugging distributed functions is harder than debugging one application, local development is more awkward, and you are more tied to a specific provider.
Good uses, and how to start
Strong fits: image and video processing triggered by upload, scheduled jobs, webhook receivers (see webhooks explained), lightweight APIs with modest traffic, and glue between services.
Poor fits: long-running computation, applications needing persistent connections, high steady traffic, and anything where consistent low latency matters more than cost.
A realistic first project: a function triggered when a file lands in object storage that generates a thumbnail and writes it back. It exercises the event model, permissions and statelessness, and it is genuinely useful.
Frameworks such as the Serverless Framework or AWS SAM handle packaging and deployment, which is otherwise fiddly. And keep functions small and single-purpose — a serverless function containing an entire application inherits every constraint above without the benefits.