What Is Serverless Computing?

Serverless computing changes the unit you rent from a cloud provider. Instead of paying for a machine that waits for work, you pay for the work itself: an invocation, a query, a gigabyte-second of execution. The servers still exist, but capacity planning, patching, and scaling move from your backlog to the provider’s, and idle time stops appearing on your bill. That shift explains the model’s trajectory: Mordor Intelligence’s January 2026 update estimates the serverless computing market at USD 32.59 billion in 2026, growing at 22.94% annually toward USD 91.56 billion by 2031.

This guide covers what serverless computing is, how it works under the hood, how it compares with traditional cloud infrastructure and with containers, its benefits and limitations, real-world use cases, security and monitoring practices, and how to decide whether it fits your workload.

What is serverless computing?

Serverless computing is a cloud execution model in which the provider allocates, scales, and manages the servers that run your code, and bills you only for the resources each request actually consumes. You deploy application logic; the provider decides how many instances of it to run at any moment, including zero. The name describes the operational experience: there are still servers, but they are no longer objects you provision, patch, or think about in units.

The model has two halves, a framing the influential Berkeley View on Serverless Computing (2019) made standard. Function as a Service (FaaS) runs your code in short-lived, event-triggered units: AWS Lambda, Azure Functions, and Google Cloud Run functions (formerly Cloud Functions). Backend as a Service (BaaS) applies the same operational contract to the stateful services around your code: databases like DynamoDB and Aurora Serverless, messaging like EventBridge, object storage, authentication. A serverless application is usually both: functions for the custom logic, managed services for everything the logic touches.

The modern era of the model dates to AWS Lambda’s launch in November 2014, and the label has since spread beyond functions. Serverless containers (AWS Fargate, Google Cloud Run, Azure Container Apps) apply the contract to arbitrary container images, and serverless query engines (Amazon Athena, BigQuery) apply it to analytics. What unifies them is the contract: no capacity to manage, scaling handled by the platform, and a bill that goes to zero when usage does.

How does serverless computing work?

Mechanically, serverless platforms are event-driven request routers wrapped around a very fast provisioning system.

 Everything starts with an event. A function is registered against one or more event sources: an HTTP request arriving at an API gateway, a file landing in object storage, a message appearing on a queue, a database row changing, a timer firing. The platform, not your code, listens for these events and decides when to run.

The platform provisions execution environments on demand. When an event arrives and no idle environment is available, the platform creates one: a lightweight, isolated sandbox (AWS builds Lambda on the open-source Firecracker microVM for exactly this), loads your runtime and code into it, and invokes your handler. This setup path is the cold start, and it adds latency to the first request. Subsequent events reuse the warm environment, so steady traffic mostly avoids the penalty; platforms also offer pre-warming options (provisioned concurrency, minimum instances) for latency-sensitive paths.

Scaling is horizontal and automatic. Concurrency is handled by running more copies: a thousand simultaneous events become up to a thousand concurrent environments, with no autoscaling policy to write. When traffic stops, the environments are reclaimed and the fleet returns to zero.

Functions are stateless and time-bounded by design. An execution environment can be created or destroyed at any moment, so durable state lives outside the function, in a database, cache, or object store, and anything in memory or on local disk is a best-effort optimization. Executions are also bounded: AWS Lambda’s documented maximum is 15 minutes per invocation, and while ceilings vary by platform (Azure’s newer plans remove the hard cap entirely), FaaS platforms are designed around invocations that run for minutes, not hours. Long-lived work is decomposed into steps and coordinated by a workflow service such as AWS Step Functions rather than run in one long process.

Billing follows execution. The meter runs per request and per unit of compute-time consumed (commonly expressed in gigabyte-seconds, memory allocated times duration), rounded at fine granularity. This is the property the rest of the model’s economics hang on: cost is a function of work done, not of capacity reserved.

The design consequences flow from these mechanics: statelessness and time limits are not arbitrary restrictions but the price of a platform that can create, multiply, and destroy your compute at will.

Serverless computing vs. traditional cloud infrastructure

Traditional cloud infrastructure (IaaS) rents you virtual machines; you choose instance sizes, install and patch the operating system, write autoscaling policies, and pay for every hour the machines run, busy or idle. Serverless inverts almost every one of those defaults.

The economic difference is the deepest one. A VM’s cost is fixed by capacity: to absorb a traffic spike you provision for the peak, and the gap between peak and average is money spent on idle cycles. Serverless prices the work itself, so spiky and unpredictable loads cost what they use. The same logic runs in reverse at high, steady utilization: a VM that is busy around the clock is cheap per unit of work, and per-invocation pricing can overtake it. Neither model dominates; they price different traffic shapes.

The operational difference compounds over time. Every VM carries a stream of undifferentiated work (OS patching, runtime upgrades, capacity reviews, autoscaling tuning) that serverless moves wholesale to the provider. For a small team, that stream is often the larger cost, and shedding it is the stronger argument for serverless than the per-request pricing. Both differences are one inversion seen twice: costs that IaaS fixes in advance, whether in reserved capacity or in operational attention, become costs that scale with the work actually done.

Serverless functions vs. containers

Functions and containers are often framed as rivals, but they answer different questions. A container is a packaging and isolation format: your application, its dependencies, and its runtime in one portable image. Serverless is an operational and billing model: who provisions capacity, and what you pay for. The real comparison is between the operational models the two artifacts are usually deployed under.

Functions (FaaS) trade control for the fullest version of the serverless contract. The platform dictates the packaging, the supported runtimes, the statelessness, and the execution ceiling; in exchange you get per-request scaling to zero and no infrastructure to define. Fit: event handlers, glue logic, spiky APIs, any workload naturally shaped like “run this code when that happens.”

Containers on an orchestrator (Kubernetes) trade the contract for control. You can run anything (long-lived processes, background daemons, GPU workloads, any language or binary), tune the runtime freely, and avoid per-platform coupling. In exchange you own cluster capacity, node upgrades, and scaling configuration, and the meter runs whether or not requests arrive.

Serverless containers occupy the middle. Platforms like Fargate, Cloud Run, and Azure Container Apps run standard container images under a serverless contract: no nodes to manage, scaling toward zero, pay-per-use billing, with fewer packaging restrictions than FaaS and longer execution allowances. For teams that want serverless operations without rewriting applications as functions, this tier is often the practical answer, and it is where much of the model’s growth now happens; Datadog’s 2025 State of Containers and Serverless report finds Cloud Run used by 70% of Google Cloud customers, alongside Lambda’s 65% adoption among AWS customers.

 In practice the choice is rarely exclusive. The same Datadog report finds that 66% of organizations using serverless functions also run at least one container orchestration service in the same cloud: functions for the event-driven edges of a system, containers for its long-running core. Treating the two as a portfolio, with workloads placed by shape rather than by ideology, is the pattern the adoption data actually shows.

Benefits of serverless computing

The benefits are the direct consequences of the contract described above.

No infrastructure management. No instances to size, no operating systems to patch, no autoscaling policies to tune. The provider’s operational surface ends where your handler begins, which converts a permanent stream of undifferentiated work into someone else’s roadmap.

Costs track usage. Scale-to-zero means development environments, internal tools, and low-traffic services cost nearly nothing between requests. Nobody has to notice that a fleet is oversized, because there is no fleet.

Elasticity is the default. Absorbing a traffic spike requires no pre-provisioning and no forecasting; the platform scales per event. Workloads with unpredictable or bursty demand get peak capacity without paying for it in advance.

Smaller units ship faster. A function is a small, independently deployable unit with its own permissions and its own lifecycle. Teams ship a change to one event handler without rebuilding or redeploying a monolith, and infrastructure code shrinks toward event wiring plus IAM.

Availability is built in. AWS Lambda and Google’s Cloud Run spread functions across multiple availability zones by default, and Azure Functions offers zone redundancy as a plan-level option; the redundancy that takes deliberate architecture on VMs arrives as a platform property or a single configuration choice.

None of these benefits is unconditional; each has a boundary that the next section maps. But they share a shape: serverless converts fixed costs (capacity, operations, redundancy engineering) into variable ones, which is exactly what early-stage products, spiky workloads, and small teams need most.

Common challenges and limitations

The model’s constraints are as structural as its benefits, and most of them trace back to the same source: the platform’s freedom to create and destroy your compute at will. Three are constraints of the execution model itself.

Cold starts. Provisioning an environment on demand adds latency to the first request after idle, and the penalty recurs on every scale-up. Steady-traffic services rarely notice; latency-sensitive, intermittently used paths do. Mitigations exist (pre-warmed capacity, runtime snapshotting, lighter runtimes), but they cost money or constrain choices, and pre-paying for warm capacity partially unwinds the pay-per-use economics.

Platform limits. Execution duration, memory, payload sizes, and ephemeral disk are all capped. Workloads that need hours of continuous compute, large in-memory state, or specialized hardware fit poorly and end up decomposed, sometimes unnaturally, into step-function choreography.

State and testing friction. Statelessness pushes every piece of durable state into external services, which multiplies integration points, and faithfully reproducing an event-driven, managed-service-heavy architecture on a laptop remains awkward despite local emulators.

The other three surface at the architecture level, in how functions, managed services, and bills compose.

Vendor coupling. The code inside a function is portable; the architecture around it is not. Event formats, service integrations, IAM models, and workflow definitions are provider-specific, and a mature serverless application is woven from dozens of them. Layers such as Knative (an open-source CNCF project) and OpenFaaS offer a portable serverless contract on Kubernetes, at the price of running the platform yourself.

Observability gets harder before it gets easier. A request that once traversed one process now hops across functions, queues, and managed services, each with its own logs. Without distributed tracing and deliberate correlation IDs, debugging becomes archaeology across services. There is no host to SSH into, by design.

Cost surprises at sustained volume. Per-invocation pricing that is negligible at low traffic can overtake reserved capacity when volume becomes high and constant. The crossover point depends on workload, but the failure mode is well known: a system designed for spiky traffic quietly becomes a steady high-volume one, and the bill scales linearly with it.

None of these is disqualifying, but they reward a specific discipline: measure latency tails, model costs at projected volume rather than launch volume, and treat the provider-specific event wiring as an architectural commitment being made consciously.

Real-world use cases for serverless computing

The workloads where serverless has become the default share a shape: event-driven, intermittent, or unpredictably scaled. Three are serving and coordination logic: code that runs when a user, webhook, or clock asks.

APIs and web backends. An API gateway routing each request to a function is the canonical pattern, strongest for APIs with spiky or unpredictable traffic, internal tools, and early-stage products where load is unknown and idle cost matters more than tail latency.

Scheduled and background jobs. Cron-triggered functions replace the dedicated utility server that every team once kept alive for nightly reports, cleanup tasks, and certificate renewals, usually the least-patched machine in the fleet.

Integration glue. Webhooks, chat-ops, SaaS-to-SaaS automation: small pieces of logic that exist to connect systems, too minor to deserve a server and ideal for a function.

The other three are data processing, where work arrives in bursts and scales out per event.

Event-driven data pipelines. A file lands in object storage and a function validates, transforms, and loads it; a stream of events fans out to processors as it arrives. Because pipeline traffic is inherently bursty (nothing for hours, then a batch), pay-per-use pricing fits it unusually well. The transformed output typically lands in a warehouse or data lake for analysis.

Media and file processing. Thumbnailing images, transcoding video segments, generating PDFs: embarrassingly parallel work that arrives in bursts and parallelizes across as many concurrent executions as the platform will grant.

IoT and telemetry ingestion. Fleets of devices produce irregular event streams that scale-per-event ingestion absorbs without a capacity plan, feeding queues and time-series stores downstream.

Across all six, the common thread is that the workload’s demand curve is decided by the outside world (users, devices, file arrivals) rather than by the system itself, which is precisely the curve capacity-based infrastructure prices worst.

Security and monitoring in serverless environments

Serverless narrows some security responsibilities and redistributes the rest. The provider patches the hardware, host OS, and runtime, taking a whole class of vulnerability management off your plate. What remains concentrates in three places: your code and its dependencies, the identity and access configuration around each function, and the event surfaces that trigger execution.

Identity becomes the perimeter. With no network boundary to stand behind, each function’s IAM role is its blast radius. The discipline that matters most is per-function least privilege: a function that reads one queue and writes one table should be able to do exactly that and nothing else. In practice roles accrete permissions over time, and the gap between what a function can do and what it does do is where incidents live.

The attack surface is the event surface. Every trigger is an input channel: API payloads, file uploads, queue messages, cross-service events. Input validation and secrets hygiene (secrets in a managed store, never in environment variables or code) carry more weight than in perimeter-defended architectures.

Monitoring means tracing, not host metrics. With no hosts to watch, observability centers on structured logs, per-function metrics (invocations, duration, errors, throttles, cold starts), and above all distributed tracing that stitches a request’s path across functions and managed services, whether through provider tooling like CloudWatch or the OpenTelemetry ecosystem. Billing telemetry belongs in the same dashboard: in a pay-per-use system, a cost anomaly is an operational alert.

The deeper difficulty is that a serverless estate is not a list of assets but a web of relationships: hundreds of functions, each with a role, each role granting actions on specific resources, each function triggered by specific event sources. The questions that matter in a review or an incident are path questions across that web: which functions can ultimately write to this bucket, what is the full reach of this role if its function is compromised, which event sources fan out into services that touch customer data. Inventory, configuration, and audit data (CloudTrail logs, IAM snapshots, resource inventories) increasingly land in a warehouse or security data lake, where those multi-hop questions become chains of SQL self-joins with the depth guessed in advance. PuppyGraph addresses that gap. It is a graph query engine that connects directly to the warehouses and lakes where this data already lives and lets you define a graph schema of functions, roles, permissions, and resources over the existing tables. Reachability and blast-radius questions then run as openCypher queries, with Gremlin also supported, with no ETL and no second copy of the data.

 Security and monitoring in serverless change shape more than they change difficulty: less surface to patch, more relationships to reason about, and tooling choices that reward teams who treat identity, tracing, and configuration data as first-class from the start.

When should you choose serverless computing?

The decision is a workload-shape question, not a modernity question.

Choose serverless when demand is spiky, unpredictable, or unknown. New products, event-driven pipelines, internal tools, and APIs with irregular traffic get elastic capacity and near-zero idle cost, the combination capacity-based pricing handles worst.

Choose serverless when the team is small relative to its operational surface. Shedding patching, capacity planning, and scaling policy is worth the platform’s constraints for teams whose scarcest resource is engineering attention.

Prefer containers or VMs when load is high and steady. Sustained utilization is where reserved capacity is cheapest per unit of work and per-invocation pricing is weakest; model the crossover with projected volume, not launch volume.

Prefer them too when the workload breaks the platform’s assumptions. Long-running processes, strict tail-latency budgets that cold starts would violate, large in-memory state, specialized hardware, or hard portability requirements all argue for keeping the process under your control, with serverless containers as the frequent compromise.

For most organizations the honest answer is a mix, and the adoption data says exactly that: two-thirds of organizations using serverless functions also run orchestrated containers alongside them, placing each workload by its traffic shape and constraints. The useful default is to let the event-driven edges of a system be serverless and to promote a workload to provisioned infrastructure only when its volume, latency profile, or runtime needs demand it.

Conclusion

Serverless computing is best understood as a change in pricing unit and responsibility boundary rather than a change in what applications do: work is billed instead of capacity, and the provider operates everything below the handler. That contract is a nearly unqualified win for event-driven, bursty, and unpredictable workloads, a real but bounded win for small teams shipping quickly, and a poor fit for steady high-volume or long-running compute, which is why mature architectures settle into a portfolio of functions, serverless containers, and provisioned infrastructure rather than a conversion to any one of them. The model also changes what operational rigor looks like: the hard problems move from patching and capacity to identity, tracing, and the web of relationships between functions, roles, and data, problems that are graph-shaped and increasingly answered from the configuration and audit data already landing in warehouses and lakes.

Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries run over warehouse and lakehouse tables, with no graph-specific ETL, turning the inventory and audit data a serverless estate produces into a queryable graph.