Serverless computing is a cloud execution model in which the provider allocates compute on demand for each event, scales it automatically from zero to thousands of parallel instances, and bills only for the resources actually consumed. Servers still exist, but provisioning, patching, capacity planning and operating-system maintenance become the provider’s responsibility rather than the customer’s.
In the cloud, the serverless model covers more than functions. Function as a Service is its best-known form, yet managed databases, queues, object storage and container platforms that scale to zero and charge per use follow the same principle. The defining traits are no server management, event-driven execution, automatic elastic scaling and pay-per-use pricing.
How serverless computing executes code
A serverless platform runs code only in response to a trigger, such as an HTTP request, a message on a queue, a new file in a storage bucket or a scheduled timer. When the event arrives, the platform routes it to a warm execution environment if one is idle, or creates a new one, loads the deployment package and runs the handler.
Each execution environment is an isolated sandbox, often a lightweight microVM, that handles one request at a time in classic function platforms. Concurrency therefore scales by adding environments, not threads. After a period of inactivity the platform reclaims idle environments, which is why the first request after a quiet period may hit a cold start, the extra latency of initializing a fresh environment.
The lifecycle below shows where time and cost accumulate during a single invocation.
| Phase | What happens | Billed to the customer |
|---|---|---|
| Event delivery | Trigger source passes the event to the platform | Usually as a request charge |
| Environment init | Sandbox starts, runtime and code load | Varies by platform and runtime |
| Handler execution | Business logic runs and returns a result | Yes, per millisecond of duration |
| Idle reuse window | Environment stays warm for later requests | No |
| Reclamation | Platform destroys the idle environment | No |
Because state in memory may disappear at any moment, serverless code must be stateless between invocations. Durable state belongs in external services such as a database, a cache or object storage.
Service models within serverless computing
Serverless computing is a spectrum of managed services, not a single product category. What unites them is that the customer configures limits and triggers instead of servers, and that cost follows demand.
| Model | Unit of deployment | Typical use |
|---|---|---|
| Function as a Service | Single function with a handler | Event processing, APIs, glue code |
| Serverless containers | Container image | Web services needing custom runtimes |
| Serverless databases | Table or database with on-demand capacity | Spiky or unpredictable read and write load |
| Serverless messaging | Queue, topic or event bus | Decoupling producers from consumers |
| Workflow orchestration | State machine definition | Multi-step processes with retries |
Function platforms impose hard execution limits. AWS Lambda, for example, caps a single invocation at 15 minutes and allows memory from 128 MB to 10,240 MB, with CPU allocated in proportion to memory. Serverless container platforms relax several of these limits and can serve many concurrent requests per instance, which narrows the gap with conventional container hosting.
Serverless compared with containers and virtual machines
The main difference between serverless computing and other hosting models is who owns capacity decisions. With virtual machines the customer sizes and pays for instances whether or not they are busy; with serverless the provider sizes capacity per event and the customer pays only while code runs.
| Property | Virtual machines | Managed containers | Serverless functions |
|---|---|---|---|
| Operating system patching | Customer | Shared | Provider |
| Scaling unit | Instance | Container replica | Individual request |
| Scale to zero | No | Sometimes | Yes |
| Billing basis | Provisioned time | Provisioned or used resources | Requests and execution time |
| Maximum run time | Unlimited | Unlimited | Minutes, platform-specific |
| Startup latency | Minutes | Seconds | Milliseconds to seconds |
The trade-off is control for convenience. Serverless removes operational work and idle cost, but it limits runtime duration, local state, network tuning and hardware choice, and it ties code more closely to the provider’s event sources and APIs.
How serverless pricing works
Function pricing usually combines a per-request fee with a duration fee measured in GB-seconds, which multiplies allocated memory by execution time. Many platforms meter duration in 1 ms increments, so short functions are billed precisely rather than rounded up to a full second.
A worked example shows the arithmetic. Assume 10 million requests per month, an average duration of 200 ms and 512 MB of memory, with illustrative rates of $0.20 per million requests and $0.0000166667 per GB-second.
| Cost item | Calculation | Result |
|---|---|---|
| Compute volume | 10,000,000 × 0.2 s × 0.5 GB | 1,000,000 GB-seconds |
| Duration charge | 1,000,000 × $0.0000166667 | About $16.67 |
| Request charge | 10 × $0.20 | $2.00 |
| Total before free allowances | $16.67 + $2.00 | About $18.67 |
The same arithmetic reveals the break-even point. At low or bursty utilization, serverless is usually far cheaper than an always-on instance; under steady, high utilization the per-unit premium accumulates, and reserved or containerized capacity often becomes less expensive.
When serverless computing fits and when it does not
Serverless computing fits best when load is irregular, event-driven or hard to predict, and when the team values delivery speed over infrastructure control.
| Situation | Recommended choice | Reason |
|---|---|---|
| Spiky API traffic with quiet nights | Serverless functions | No cost while idle, instant scaling |
| File or message processing pipeline | Serverless functions | Natural fit for event triggers |
| Steady high-throughput service | Containers or reserved instances | Lower unit cost at constant load |
| Jobs running longer than 15 minutes | Containers or batch services | Function time limits |
| Strict sub-10 ms tail latency | Pre-warmed or always-on compute | Cold starts add unpredictable delay |
| Specialized hardware such as GPUs | Virtual machines or managed clusters | Limited hardware choice in functions |
Limitations and common mistakes
Most serverless problems come from treating functions like small servers. The following pitfalls appear repeatedly in production systems.
- Ignoring cold starts: large packages, heavy frameworks and VPC attachment can lengthen initialization; provisioned or minimum instances reduce it at extra cost.
- Overwhelming downstream systems: thousands of parallel functions can exhaust database connection limits; connection pooling proxies and concurrency caps prevent this.
- Assuming exactly-once delivery: many event sources deliver at least once, so handlers must be idempotent.
- Chaining functions synchronously: one function waiting on another pays twice for the same time; queues or orchestration services avoid this.
- Losing visibility: short-lived, distributed executions need structured logs, metrics and traces from the start.
- Underestimating lock-in: triggers, permissions and event formats are provider-specific, which raises migration cost later.
The simple explanation
Serverless computing works like a taxi instead of a car you own. You do not buy the vehicle, insure it or park it. You call a ride when you need one, and you pay only for the trip.
With serverless, a company writes a small piece of code and hands it to a cloud provider. The provider runs it only when something happens, such as a customer clicking a button, and charges for those moments alone. No traffic means almost no bill, and a sudden rush is handled automatically. The catch is that you accept the provider’s rules about how long each job may run and how it starts.
How it is used in practice
An online photo service lets users upload pictures that must be resized into four formats. Uploads arrive unevenly: a few hundred per hour overnight, but more than 50,000 per hour after a popular marketing email. Running enough servers for the peak would leave them almost idle most of the day.
The team configures each upload to object storage to trigger a function with 1,024 MB of memory that creates the four sizes in about 800 ms. During the peak the platform runs hundreds of copies in parallel, and overnight it scales down to zero. Because image processing can be retried, the handler is written to be idempotent, overwriting the same output files if an event arrives twice.
The result is no capacity planning, consistent processing times during spikes and a monthly bill that tracks the number of uploads rather than the size of a server fleet.