serverless computing

Serverless computing is a cloud execution model in which the provider allocates machine resources on demand, runs application code only while it’s handling an event such as an HTTP request or a file upload, and bills for that time alone. Servers still exist. The team never provisions, patches, or scales them, which is where the name comes from.

Martin Fowler’s definition of serverless architecture splits the model into two halves that usually appear together. Backend as a service, or BaaS, replaces code the team would otherwise write with a hosted product such as a managed database or an authentication service. Functions as a service, or FaaS, keeps the custom code but runs it in stateless containers that are event-triggered, short-lived, and fully managed by the provider.

Say a team needs to accept payment webhooks that arrive a few dozen times a day. Under FaaS, the whole deployable unit is one function that the platform calls with the event, so there’s no web server to run and no port to bind:

Python 
>>> import hashlib
>>> import hmac

>>> SECRET = b"s3cr3t"

>>> def handle_webhook(event, context):
...     expected = hmac.new(
...         SECRET, event["body"].encode(), hashlib.sha256
...     ).hexdigest()
...     if hmac.compare_digest(event["headers"]["x-signature"], expected):
...         return {"statusCode": 202, "body": "accepted"}
...     return {"statusCode": 401, "body": "invalid signature"}
...

>>> handle_webhook(
...     {"headers": {"x-signature": "deadbeef"}, "body": '{"id": 42}'},
...     None,
... )
{'statusCode': 401, 'body': 'invalid signature'}

AWS Lambda calls that entry point the handler, and Google Cloud Run functions and Azure Functions use the same event-in, response-out shape.

How It Shows Up in Practice

A Python developer usually meets serverless as a repository of small handler modules sitting beside a deployment manifest, such as a serverless.yml, an AWS SAM template, or a Terraform module. A pipeline packages the code and pushes it to the provider, so the manifest is as much infrastructure as code as any server definition.

The runtime gets pinned much the way a container image pins it. AWS Lambda exposes Python through runtime identifiers such as python3.14 and caps a single invocation at fifteen minutes. Billing is per request plus gigabyte-seconds, which multiply the memory allocated to the function by how long it runs, rounded up to the nearest millisecond.

Teams rarely go all in. A common split runs the steady request path as a microservice and offloads spiky or scheduled background work to functions.

Debugging shifts too. There’s no long-lived process to attach to, so failures are diagnosed from the provider’s logs and traces, which makes observability the primary interface to a running function.

Cold Starts and Scaling to Zero

Scaling to zero is the main benefit. With no traffic, no execution environments exist and the function costs nothing, and a sudden burst is absorbed by the provider starting more copies without any capacity planning from the team.

The price of that elasticity is the cold start, as AWS Lambda documents it. When no environment is available, the provider creates one, initializes the runtime, imports the module, and only then calls the handler. A reused environment skips that setup and is called a warm start. Cold starts are what make heavy import-time work expensive and put a floor under tail latency, the response time of the slowest requests.

In the timeline below, each row is an execution environment and time runs left to right, so adding traffic marks which invocations pay for that setup and which skip straight to the handler:

Interactive diagram — enable JavaScript to view.

Short-lived environments also push state outward. Anything that must survive between invocations belongs in a database, a cache, or object storage rather than in module-level variables, the same discipline a twelve-factor app applies to its processes. Portability is the remaining tradeoff, since triggers, packaging, and limits differ by provider, so moving a serverless application between clouds is rarely a lift and shift.

Building Serverless Apps Using AWS Chalice

Tutorial

Building Serverless Python Apps Using AWS Chalice

Build and deploy a serverless Python app with AWS Chalice, a microframework that ships your code to AWS Lambda and scales it for you.

intermediate web-dev

For additional information on related topics, take a look at the following resources:

Have a question about this? Mentor AI can show you examples, compare related terms, and point you to tutorials.

  • Ask Mentor AI
  • Pick a question and Mentor AI takes it from here.
By Martin Breuss • Updated Oct. 21, 2026
Software Engineering Glossary Share Feedback