What Is Serverless Computing? A Plain-English Explainer

Serverless computing is a way of running code in the cloud where the provider — not you — owns the servers, the operating system, and the scaling logic. You upload a function or a small application, attach it to a trigger such as an HTTP request or a file upload, and the platform runs it only when that trigger fires, then bills you for roughly the compute time actually used. Despite the name, servers are still involved; what disappears is your job of provisioning, patching, and scaling them.

That single idea — code that runs on demand, on infrastructure you never touch, billed by execution rather than by the hour — is the thread connecting AWS Lambda, Cloudflare Workers, Google Cloud's Cloud Run functions, Azure Functions, and the edge functions built into Vercel and Netlify. This guide walks through what "serverless" actually means, how it differs from virtual machines and from containers like Docker and Kubernetes, who the major players are, why cold starts matter, and the situations where serverless is the wrong tool for the job.

What "serverless" actually means

"Serverless" is something of a misnomer — the Cloud Native Computing Foundation's own serverless working group has noted as much, since the provider is still running physical or virtual servers underneath every function invocation. What the term describes is a division of responsibility: the cloud provider handles the server, the operating system, security patching, and capacity planning, while the developer is responsible only for the application code. AWS states this plainly in its Lambda documentation, describing the service as one where "you can run code without provisioning or managing servers," because AWS "automatically manages the underlying infrastructure — including server maintenance, capacity provisioning, scaling, and patching."

In practice, "serverless" usually bundles together four characteristics:

Most serverless platforms today fall under the umbrella of Function-as-a-Service (FaaS): you write a function with a defined entry point, the platform wraps it in a managed runtime, and it invokes that function whenever a configured event occurs. AWS Lambda, Google's Cloud Run functions, and Azure Functions are all FaaS platforms. Some newer offerings, like Vercel and Netlify's edge and serverless functions, apply the same on-demand, no-infrastructure model to code that sits directly in front of a web request rather than behind a separate event bus.

Serverless vs. traditional virtual machines

A traditional virtual machine is the opposite end of the spectrum. You (or your infrastructure team) choose an instance size, install an operating system, deploy your application onto it, and that VM keeps running — and costing money — whether or not it's handling traffic. If demand spikes, someone has to add more VMs, either manually or through autoscaling rules you configure and maintain. If a security patch ships for the OS, that's your job too.

Serverless removes nearly all of that operational surface. There's no instance to size, no OS to patch, and no idle capacity to pay for, because a function that isn't being invoked isn't running at all — it scales to zero. The tradeoff is control: you give up the ability to tune the underlying machine, choose exotic hardware, or keep a process "warm" indefinitely without paying for mechanisms designed for that purpose, such as AWS Lambda's provisioned concurrency.

Serverless vs. containers and Kubernetes

Containers sit between VMs and serverless on the management spectrum. A tool like Docker packages an application with its dependencies into a portable image, and an orchestrator like Kubernetes schedules, scales, and restarts those containers across a cluster of machines you still own or rent. Our explainer on how Kubernetes orchestrates containers covers that model in more depth — the short version is that you still manage the cluster itself, even though individual containers are easier to move and scale than a full VM.

Serverless platforms often use containers or lightweight virtualization under the hood — AWS Lambda, for instance, isolates each execution environment using its Firecracker microVM technology — but that detail is invisible to the developer. You never write a Dockerfile, never run kubectl, and never decide how many nodes a cluster needs. Cloudflare takes a different approach entirely: Workers run inside V8 isolates rather than containers or VMs, which Cloudflare's own documentation says lets an isolate start "around a hundred times faster than a Node process on a container or virtual machine," with roughly an order of magnitude less memory overhead at startup.

This isn't an either-or choice for most engineering teams. It's common to run a Kubernetes cluster for steady, stateful workloads while handing bursty, event-driven pieces of the same application to a serverless function.

The major serverless platforms

Every major cloud provider, plus several frontend-focused hosts, now offers a serverless compute product. They share the same core model but differ in execution environment, language support, and where in the world the code actually runs.

AWS Lambda remains the default reference point for FaaS, in large part because it launched the category in 2014 and ties directly into the rest of AWS. Cloudflare Workers takes a distinct architectural path built for very fast, globally distributed execution rather than deep integration with a single cloud's backend services. Google's and Microsoft's offerings sit closer to Lambda's model but plug into their own respective service ecosystems. Vercel and Netlify, meanwhile, built their serverless and edge functions primarily to support the frontend frameworks and sites they host, so a request can hit a small piece of server-side logic — an API route, an A/B test, a personalization check — without the team running a separate backend.

Cold starts: the tradeoff that comes with scaling to zero

Scaling to zero is the feature that makes serverless cheap when idle, but it has a cost of its own: the first request to a function that isn't already running has to wait for a new execution environment to be created. AWS describes this directly in its Lambda operator guide: when the first two steps of an invocation — downloading the code and setting up the environment — happen before your handler runs, "this is frequently referred to as a 'cold start.'" The same guide reports that cold starts "typically occur in under 1% of invocations," with duration ranging "from under 100 ms to over 1 second," and that they're more common for infrequently invoked functions than for busy production workloads, because an environment that's already warm from a recent request can usually be reused.

Providers address this differently. AWS offers provisioned concurrency to pre-initialize a set number of execution environments in advance, keeping them warm at an additional cost. Google Cloud lets you configure minimum instances on Cloud Run functions for the same reason. Cloudflare sidesteps the problem architecturally: because Workers run in lightweight V8 isolates rather than spinning up a full containerized runtime, Cloudflare's documentation describes isolate startup as roughly a hundred times faster than booting a Node process in a container or VM. Vercel's "fluid compute" model takes a related approach, reusing a single function instance across concurrent requests to cut down on the number of fresh starts needed in the first place.

The practical upshot: if your workload is latency-sensitive and traffic is unpredictable or bursty, cold starts are a real design constraint, not a footnote. If traffic is steady enough that functions stay warm, or if you're willing to pay for pre-warmed capacity, the impact shrinks considerably.

What serverless is actually good for

Serverless computing tends to fit workloads that are short-lived, bursty, or naturally triggered by an event rather than kept running continuously:

• APIs and webhooks. A function that handles a single API request, processes a webhook from a third-party service, or responds to a form submission is a near-perfect fit — it does one job and exits.
• Event-driven data processing. Resizing an image after it's uploaded to storage, parsing a file that lands in a queue, or reacting to a database change are classic FaaS triggers across AWS, Google Cloud, and Azure.
• Scheduled and background jobs. Nightly cleanup tasks, report generation, and cron-style jobs that don't need a server running between executions.
• Edge logic for web apps. Cloudflare Workers and Vercel/Netlify's edge functions are commonly used for things like authentication checks, redirects, A/B testing, and personalization that need to run close to the visitor, in front of a cached page.
• Unpredictable or spiky traffic. Because billing follows usage and scaling is automatic, serverless absorbs sudden traffic spikes without the team pre-provisioning capacity for a peak that might not recur.

When not to reach for serverless

Serverless isn't a universal replacement for servers, containers, or VMs. A few situations tend to push teams back toward more traditional infrastructure:

• Long-running workloads. Most FaaS platforms cap execution duration — AWS Lambda's standard limit is 15 minutes per invocation, for example. Workloads like large video transcoding jobs, long training runs, or anything that needs to hold a connection open for hours is a poor match for a model built around short, stateless invocations.
• Predictable, steady, high-volume traffic. Pay-per-execution pricing is attractive when usage is spiky or low, but a service that runs at consistently high, predictable volume around the clock can end up costing more on a per-request billing model than on reserved or bulk-provisioned servers sized for that exact load.
• Workloads that need persistent in-memory state. Execution environments are frozen, reused opportunistically, and eventually torn down; AWS explicitly warns against assuming an environment "will persist indefinitely." Anything that needs a long-lived in-memory cache or a stateful connection pool managed outside the platform's own bindings needs a different architecture.
• Vendor lock-in concerns. Each platform's triggers, bindings, and event formats are proprietary. The CNCF has pointed to "a lack of standardization and interoperability between cloud providers" as a driver of lock-in, and backend-as-a-service integrations in particular tend to assume everything is running on a single vendor's stack — migrating a deeply integrated serverless application to another cloud is rarely a drop-in process.
• Fine-grained control over the runtime. If you need a specific kernel setting, a custom networking configuration, or hardware like GPUs that a given FaaS platform doesn't expose, a VM or a self-managed container cluster still gives you that control directly.

How pay-per-execution pricing actually works

Pricing details vary by provider and change over time, so treat the following as illustrative rather than exhaustive — always check each vendor's current pricing page before budgeting. AWS Lambda, as one documented example, charges per request plus compute time measured in GB-seconds, with a free tier AWS lists as "one million requests and 400,000 GB-seconds per month." Azure Functions similarly advertises a monthly free grant of up to 1,000,000 executions on its consumption-based plans. The shared idea across providers is that cost scales with actual usage: a function that never runs costs nothing beyond storage, and a function that runs constantly at high volume should be compared carefully against reserved compute, since steady, heavy use is exactly the scenario where traditional servers can come out cheaper.

What's next for serverless

The lines between serverless, containers, and edge computing keep blurring. AWS now offers Lambda "Web Functions" that run full HTTP servers inside the same serverless billing model it built for single-purpose event handlers, and it has introduced Lambda MicroVMs for workloads that need a longer-lived, isolated environment per user or job — a sign that FaaS platforms are expanding beyond short, stateless invocations. Google's Cloud Run functions already run on the same underlying platform as its container service, letting teams move between a function and a full container without switching products. Cloudflare, Vercel, and Netlify continue pushing execution closer to the end user through edge networks, chipping away at the cold-start and latency concerns that have historically been serverless's biggest limitation.

For most teams, the practical path isn't choosing serverless or containers or VMs once and for all — it's matching each workload to the model that fits it, often within the same application. A steady backend service might run in containers; a bursty webhook handler or an edge personalization check might run as a function. Understanding what "serverless" actually buys you — and what it costs when a workload doesn't fit its assumptions — is what makes that decision possible.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage