In short
Serverless is a cloud model in which you deploy code as functions that the provider runs on demand, scaling from zero to thousands of instances automatically and billing per invocation and execution time, with no servers to provision, patch or size; AWS Lambda, Cloudflare Workers, Vercel and Netlify Functions, and Google Cloud Functions are examples. It suits event-driven, bursty and low-traffic workloads, APIs behind static sites, and glue between services. Its costs are cold-start latency, execution limits, harder debugging, and bills that can exceed a fixed server at sustained high load.
The model
Traditionally an application runs on a server that is always on: you provision it, size it for peak, patch it, monitor it and pay for it whether or not anyone is using it. Serverless inverts this. You write functions, small units of code that handle a request or an event, and hand them to a provider. When a request arrives, the provider starts an instance of the function, runs it, returns the result, and, after a period of inactivity, shuts it down. Traffic spikes spawn more instances; silence costs nothing. You are billed for invocations and for the milliseconds of execution.
AWS Lambda launched the category in 2014. Today most cloud providers and front-end platforms offer a version: Cloudflare Workers, which run at the edge in hundreds of locations; Vercel and Netlify Functions, integrated with static and framework hosting; Google Cloud Functions, Azure Functions, and container-based cousins such as Cloud Run and AWS Fargate that run whole containers on the same pay-per-use, scale-to-zero basis.
Serverless also describes managed services that behave the same way, such as databases, queues and storage that scale and bill on use, so "a serverless architecture" often means an application assembled from such services with functions as the glue.
What it removes
Server provisioning and sizing. Operating system patching. Capacity planning for peaks. Paying for idle time. Most of the operational load that small teams struggle to carry. For a team without an infrastructure specialist this is the strongest argument: the provider runs the machines and the team runs the code.
Where it suits
APIs behind static sites. A static site with a few functions for forms, search, bookings or payments is the archetypal serverless setup: the site is files on a CDN, the dynamic bits run on demand, and the whole thing costs almost nothing at small scale.
Event-driven work. Processing an upload when it arrives, sending an email when an order is placed, resizing an image, reacting to a webhook. Work that happens in response to something and then stops.
Bursty and unpredictable traffic. A campaign landing page, a ticket release, a seasonal service. Scaling from zero to thousands and back without anyone touching anything.
Scheduled jobs. Nightly reports, cleanups, syncs, replacing a server kept alive to run cron once a day.
Glue between services. Small transformations and integrations that would not justify a server of their own.
Edge logic. Redirects, personalisation, authentication checks and A/B assignment running at the CDN node nearest the visitor.
The traps
Cold starts. A function that has not run recently must be started before it can respond, adding anywhere from tens of milliseconds to a couple of seconds depending on the runtime, the package size and the provider. For user-facing requests this is visible latency; for background work it is irrelevant. Edge runtimes and smaller functions reduce it; keeping functions warm costs money.
Limits. Execution time (often 10 seconds to 15 minutes), memory, payload size, and the number of concurrent instances. Long-running work, large files and persistent connections such as WebSockets fit badly or not at all.
Cost at sustained load. Pay-per-use is cheap when usage is low and expensive when it is constant. An API handling steady heavy traffic often costs more as functions than as a couple of always-on containers. Model the cost at expected volume before assuming serverless is cheaper.
Debugging and observability. Many short-lived instances, distributed logs, no server to log into. Tracing a request across functions and services needs tooling that a single server does not.
State. Functions are stateless by design; anything that must persist goes in a database or cache, which means every function call may pay a connection cost. Connection pooling to traditional databases is a known pain point, and serverless-native databases exist partly to solve it.
Vendor coupling. Function signatures, triggers and the managed services around them differ by provider. Moving is a rewrite of the edges, though usually not of the logic.
Architectural sprawl. An application split into a hundred tiny functions is hard to reason about, and the "serverless means microservices" instinct produces systems more complex than the problem.
The middle ground
Container platforms such as Cloud Run, Fly.io and Render run an ordinary application, a whole web server, on the same scale-to-zero, pay-per-use basis, without cold-start-per-request behaviour and without splitting it into functions. For many products this is the better answer: the simplicity of a conventional application with the operations of serverless. The case for boring technology applies here as much as anywhere.
The decision
Use functions for the dynamic parts of a static site, for event-driven and scheduled work, for glue and for edge logic. Use a container platform for an application with sustained traffic, long requests or persistent connections. Use a plain server when the team knows how to run one and the workload is steady and predictable. And model the bill at real volumes before choosing on cost, because the pricing is deliberately hard to compare. If you are designing the infrastructure for a new product, book a call; the split between static, functions and containers is usually clear once the workload is described.
Common questions
What does serverless mean?
Running code as functions that a cloud provider executes on demand, scaling automatically from zero to many instances and billing per invocation and execution time, with no servers for you to provision, patch or size. Servers still exist; the provider manages them. The term also covers managed services such as databases and queues that scale and bill the same way.
What is a cold start in serverless?
The delay when a function that has not run recently must be initialised before it can handle a request, typically tens of milliseconds to a couple of seconds depending on runtime, package size and provider. It matters for user-facing requests and not for background work; smaller functions and edge runtimes reduce it.
Is serverless cheaper than a server?
At low or bursty usage, usually far cheaper, since idle time costs nothing. At sustained high load it can cost more than fixed containers or servers, because per-invocation pricing adds up. Model the cost at your expected volume; the answer changes with traffic shape, and the pricing is not easy to compare by eye.
What is serverless good for?
APIs and dynamic features behind static sites, event-driven work such as processing uploads and sending notifications, scheduled jobs, bursty traffic, integrations between services, and edge logic such as redirects and authentication checks. It suits work that happens in response to something and then stops.
What are the disadvantages of serverless?
Cold-start latency, execution time and memory limits, poor fit for long-running work and persistent connections, harder debugging across many short-lived instances, connection overhead to traditional databases, provider-specific code at the edges, and bills that can exceed a fixed server under constant load. Splitting an application into too many functions also adds complexity.
