What Is Serverless? Functions, Scaling, and Cost

Serverless is a cloud execution model where you deploy code — often individual functions — and the platform takes care of provisioning servers, scaling capacity, and ensuring availability. You don’t reserve or manage any machines. Servers still exist, of course; the name means you don’t think about them. You pay only for the compute time your code actually uses, down to the millisecond.

Functions-as-a-Service

The most common form of serverless is Functions-as-a-Service (FaaS). You write a function with a well-defined trigger — an HTTP request, a queue message, a file upload, a scheduled timer — and the platform runs it on demand.

The two most widely used FaaS platforms are AWS Lambda and Cloudflare Workers. Lambda runs in AWS data centers and supports a broad set of runtimes (Node.js, Python, Java, Go, and more). Workers runs at Cloudflare’s global edge network — meaning the function executes in a data center close to the user rather than in a single region.

A minimal Cloudflare Worker looks like this:

export default {
  async fetch(request) {
    return new Response("Hello from the edge!");
  }
};

Deploy it, and Cloudflare handles routing, scaling, and TLS. No configuration of servers, load balancers, or auto-scaling groups required.

Managed backend services

Serverless extends beyond functions. Cloud providers offer fully managed services for databases (Amazon DynamoDB, PlanetScale, Neon), authentication, queues, object storage, and more — all billed per use with no capacity planning. These are sometimes called Backend-as-a-Service (BaaS) components. Combined with FaaS, they let you build complete applications without managing any infrastructure.

Cloudflare’s developer platform, for example, pairs Workers with R2 object storage, D1 (a serverless SQLite database), and KV for global key-value storage. For a broader view of what Cloudflare has assembled around this model, see Cloudflare’s developer platform expansion.

Benefits

Automatic scaling. The platform scales your function from zero to thousands of concurrent executions and back to zero automatically. There’s no need to predict traffic or provision headroom. A function that receives one request per day and one that receives a million are managed identically by the operator.

Pay-per-use pricing. You’re billed only when your function runs, usually measured in request count and GB-seconds of compute. Idle functions cost nothing. This is a significant shift from reserved EC2 instances or VMs that accrue cost around the clock.

Reduced operational burden. No patching, no capacity planning, no on-call for server health. The platform handles OS updates, hardware failures, and availability.

Fast deployments. Pushing a new function version is typically a matter of seconds, with no server restart or rolling deployment to orchestrate.

Trade-offs

Serverless is not universally the right choice. Several genuine constraints apply.

Cold starts. When a function hasn’t run recently, the platform must initialize a new execution environment before handling the request. This adds latency — from a few milliseconds on edge platforms to several hundred milliseconds on some Lambda runtimes with large dependencies. Cold start mitigation strategies exist (keeping functions warm, provisioned concurrency) but add cost and complexity.

Execution limits. FaaS platforms impose maximum execution durations (Lambda defaults to 15 minutes; Workers to a few seconds on the free tier, minutes on paid plans) and memory caps. Long-running workloads — batch jobs, video processing, model training — are generally a poor fit.

Statelessness. Functions are stateless by design. Any state that needs to persist across invocations must be stored externally: in a database, a cache like Redis, or an object store. This is a feature — it’s what enables horizontal scaling — but it requires designing data flows carefully.

Vendor lock-in. Each platform has its own APIs, runtime quirks, and deployment tools. Migrating a serverless application from AWS Lambda to Google Cloud Functions or Cloudflare Workers requires rework. Using platform-agnostic frameworks (like SST or Serverless Framework) helps, but some coupling is unavoidable.

Local development friction. Reproducing a FaaS environment locally is harder than running a traditional Node or Python server. Emulators exist but don’t always match production behavior exactly.

Edge functions

A growing category of serverless is edge functions — code that runs at the CDN layer, close to end users, rather than in a centralized region. Cloudflare Workers, Vercel Edge Functions, and Deno Deploy all fall into this category. Because the function runs in the nearest of hundreds of global points of presence, latency is dramatically lower than routing requests to a single US-East data center.

Edge functions work well for request transformation, authentication, A/B testing, and personalized responses. For more on the infrastructure that makes this possible, see what is a CDN and the rise of edge databases.

Deploying an Astro site to Cloudflare Pages, for instance, lets you add edge middleware that runs in the same network layer as the static assets — see the guide on deploying Astro to Cloudflare Pages. Unlike a traditional origin server, there’s no single machine to fail or scale; the edge handles distribution automatically.

Serverless vs. containers

Containers (Docker, Kubernetes) give you more control: custom runtimes, long-running processes, stateful workloads, and portable deployments. Serverless trades that control for simplicity and cost efficiency on bursty, short-lived workloads. Many architectures use both: a Kubernetes cluster for core services alongside Lambda functions for event-driven tasks like image resizing or webhook processing. For CDN-fronted deployments, what is a load balancer explains how traffic is distributed across container-based services.

The takeaway

Serverless lets you ship and run code without managing infrastructure. The platform handles scaling — including scaling to zero — and you pay only for actual use. It fits best with short-lived, stateless, event-triggered workloads where operational simplicity and elastic scaling matter more than runtime flexibility or low latency on first call. For most modern web APIs, background jobs, and edge middleware, it’s a compelling default.