What is serverless? Architecture, benefits, and costs

Serverless is a cloud computing model in which a provider manages the servers that run your application. You write code, the platform runs it on demand, and usage helps determine the cost. This guide explains how serverless scales, deploys, and performs, plus its costs and when it's the right choice.

What is serverless architecture?

With serverless, the provider manages the servers and adjusts capacity as demand changes. A request invokes your code, and the platform may reuse the same execution environment for later requests. You cannot rely on that environment retaining memory or local files between invocations.

That model fits workloads that spike and dip: APIs, image processing, marketing sites, anything with unpredictable traffic. It fits less well for workloads that need a constant, always-warm connection (more on that under Costs and limitations).

Scaling

Serverless scales by allocating compute as demand increases. Concurrent requests may run in separate instances or share an instance, depending on the platform.

The platform manages this capacity as traffic rises and falls, reducing the infrastructure work for developers. Automatic scaling still operates within provider limits.

The trade-off is startup time. When no suitable instance is ready, a function may need to initialize its runtime and dependencies before it can respond. This is called a cold start. Bundling code and keeping dependencies small can help, but startup time varies by platform and workload.

Global deployment

Some serverless platforms let you deploy functions across regions or at the edge. Where a request executes depends on the provider and your configuration. A request from Tokyo can run near Tokyo if the platform supports that placement.

Static assets already use a CDN to reach users around the world. On platforms with edge execution, a request can hit a nearby location, invoke a function there, and cache its response.

Headless CMS content fits this pattern well. Pages can be cached, while content that needs to be fetched for each request can be rendered dynamically.

The part that doesn't move as easily is data. If a database lives in one region, a function running in another still makes that round trip. Placing functions near their data can reduce this latency. Replication or regional databases can also bring data closer to where it's used.

Developer experience

The clearest win of serverless isn't performance. It's how much friction it removes from shipping code.

On platforms with Git-based deployment, a command or git push can trigger a build and deployment. Each commit can get its own live URL, so a pull request comes with a working preview a teammate can click through.

• Each branch can get a working preview, depending on the hosting platform and configuration
• Platforms with rollback support can point traffic at a previous deployment instead of rebuilding it
• Old versions can remain reachable for comparison, depending on the platform's retention settings

Hosted previews can reduce the gap between testing and production, though environment settings and connected services can still differ.

Performance

Serverless can help an application handle traffic spikes by adjusting capacity automatically. Response times still depend on cold starts, available capacity, and the services each function calls.

Two sources of latency are initializing a new function instance and reaching data that lives somewhere else. Small, focused functions can reduce startup work. Caching, whether at the CDN layer or through cache headers, can serve a reusable response without running the function again.

Done well, serverless lets you mix static and dynamic content: serve reusable responses from cache and compute fresh ones when needed. Use your framework's rendering options and cache headers to control that behavior.

Costs and limitations

Serverless function pricing is often based on requests and compute usage. The total cost depends on the provider and the other services your application uses.

• Costs are usage-based. On-demand functions can avoid idle compute charges, but storage, data transfer, and reserved capacity may still cost money. More traffic can increase the bill
• Cold starts add latency. An infrequently used function pays a startup cost its always-on equivalent wouldn't
• Execution time and memory are capped. Long-running jobs or anything needing a persistent in-memory connection is a worse fit for short-lived, stateless functions
• Vendor patterns vary. Moving a serverless architecture between providers usually means more rework than moving a container

None of this rules serverless out. It just means the model fits some workloads and not others, which is the actual question worth asking.

When serverless is the right choice

Serverless tends to be the right call when:

• Traffic is spiky or unpredictable, and paying for constant capacity would mean paying for a lot of idle time
• Your team benefits from the deployment, preview, and rollback tools offered by the hosting platform
• The workload breaks down into short, independent tasks: API endpoints, page renders, scheduled jobs, event handlers

It's a worse fit when:

• You need long-running processes, persistent connections, or heavy in-memory state
• Your measurements show that fixed capacity costs less for steady, predictable traffic
• Cold-start latency is unacceptable on a specific request path, though edge functions and keep-warm strategies narrow this gap

A hybrid approach can also work: serverless for bursty, user-facing tasks and a different model for steady background work.

Modern serverless examples

The pattern has matured well past its original one-function-one-endpoint shape.

• Next.js can combine static pages with dynamic routes. On compatible hosting platforms, dynamic routes can run as serverless functions
• Cloudflare Workers run functions across hundreds of edge locations, built for latency-sensitive logic that needs to sit close to the user
• AWS Lambda supports event-driven workloads triggered by HTTP requests, file uploads, or queue messages
• Framework caching, such as Next.js Cache Components, can combine cached content with dynamic data in one page

The throughline across all of them: you write the function, the platform decides where and when it runs.