Serverless functions (FaaS)
Upload a function; the cloud runs it only when something happens.
12 technologies on this page ↓How it works
You write a handler and choose what triggers it: an HTTP request, a new file, a queue message, a schedule. The platform starts instances on demand, runs as many in parallel as traffic needs, and shuts them down when idle. You pay per invocation and per millisecond of runtime, and there are no servers for you to patch.
A taxi instead of a car you own. It shows up when you call, you pay for the ride, and insurance and parking are someone else’s problem.
Reach for it when
- Event-driven glue: resize an image on upload, react to a queue message
- Spiky or low traffic, where idle servers would waste money
- Scheduled jobs and small APIs
Think twice when
- Work that runs longer than the limit (15 minutes on AWS Lambda)
- Latency-critical paths that can’t absorb an occasional cold start
- Steady high throughput, where an always-on container is usually cheaper
A real example
Every time a sensor gateway uploads a compressed batch, a function unpacks it and writes the readings to the database. At night there are no uploads, so nothing runs and nothing is billed.
Technologies
Specific products, and what each does differently.
AWS LambdaAWSAWS’s functions service: upload a handler, connect a trigger, and pay per request and per millisecond.
AWS FargateAWSRuns ECS tasks and EKS pods without servers: you size each task, AWS finds the machine.Mainly Containers AWS Lambda | Managed service on AWS | Amazon Web Services | Proprietary | 2026-10-05 |
| Open source | Beam | AGPL-3.0 | 2026-10-06 | |
| Commercial product | Cloudflare, Inc. | Proprietary (the Puppeteer and Playwright forks are open source) | 2026-10-12 | |
| Commercial product | Cloudflare, Inc. | Proprietary (the workerd runtime is Apache 2.0) | 2026-10-05 | |
| Fission | Open source | Fission project (started at Platform9) | Apache 2.0 | 2026-10-06 |
| Open source | Cloudflare, Inc. | Apache 2.0 | 2026-10-12 | |
| Commercial product | Cloudflare, Inc. | Proprietary (the models carry their own open licenses) | 2026-10-12 | |
AWS Fargate | Managed service on AWS | Amazon Web Services | Proprietary | 2026-10-05 |
| Managed service on Google Cloud | Google Cloud | Proprietary | 2026-10-05 | |
| Open source | Anomaly Innovations | MIT | 2026-10-06 |
Also used for serverless functions (faas)
Products of other kinds that are often used this way, grouped by what they are.
| Containers | Commercial product | Cloudflare, Inc. | Proprietary | 2026-10-12 | |
| Actor model | Open source | Deno Land Inc. | Apache 2.0 | 2026-10-12 |
What each provider calls it
- AWS
- Lambda
- Google Cloud
- Cloud Run functions
- Azure
- Azure Functions
- Open source & others
- OpenFaaS, Knative, Fission (functions on Kubernetes), Beta9 (GPU functions and sandboxes, AGPL), Cloudflare Workers
See it in a real stack
Architectures that use serverless functions (faas)
In code · python
# handler.py: runs once per event
import json
def handler(event, context):
order = json.loads(event["body"])
total = sum(i["price"] * i["qty"] for i in order["items"])
return {"statusCode": 200, "body": json.dumps({"total": total})}Worth exploring
kubectl on start) that runs kubectl commands against a cluster, used here to launch a Kubernetes Job in response to an event. It is written for Cloudfleet’s own managed Kubernetes and its CLI, so the authentication steps need changing for other clusters, and passing raw kubectl arguments in an event is fine for a demo but too permissive for production.kubectl apply a Function manifest that points at code in S3. It explains why you might (one GitOps and RBAC model for pods and functions) but, being AWS’s own post, not the drawbacks.aws-auth ConfigMap, and it routes application traffic through the cluster’s control plane.lambci/docker-lambda images (since deprecated in favour of AWS’s official Lambda base images) and to Knative; read it mainly for the question, which is a common one, rather than for current tooling.Often confused with
Where it came from2008–2025
Cloud platforms had been hiding servers for a while before anyone called it serverless. Google App Engine’s 2008 preview ran web apps without machines to manage, in exchange for strict rules such as code written only in Python and responses due within a few seconds. In October 2012 Ken Fromm wrote in ReadWrite that cloud apps were “moving into a serverless world”. The word didn’t mean servers would vanish: “It simply means that developers no longer have to think that much about them.”
AWS Lambda, announced in November 2014, turned that into a concrete model. You uploaded a single function, said which event should run it (a file landing in S3, a change in DynamoDB, a record in Kinesis) and paid per request plus each 100 milliseconds of compute. Microsoft announced Azure Functions on March 31, 2016, Google’s Cloud Functions reached general availability in 2018, and Cloudflare Workers (2017) ran functions at the network edge in lightweight V8 isolates. In 2019 a Berkeley paper predicted that serverless “will grow to dominate the future of cloud computing”.
The model has since stretched: Cloud Run applied it to whole containers in 2019, and AWS’s durable functions (2025) let a function pause and resume across long workflows.
Why it’s built this way
- Code runs in response to events
- Instead of a server waiting for work, the platform starts your code when something happens. That turned cloud services into building blocks you could glue together with small functions.
- Pay per invocation and per slice of runtime
- Billing in fractions of a second means idle code costs nothing and capacity scales to zero. The trade-off is the cold start when a new instance has to be created.
- Short-lived, stateless instances
- Early platforms capped requests at a minute and kept no local state, so they could start, stop and move instances freely. State lives in databases and queues instead.
- Fast, strongly isolated sandboxes
- Running strangers’ code in thousands of tiny instances needs isolation that starts in milliseconds, which is why platforms built V8 isolates (Cloudflare) and microVMs (AWS Firecracker).
Timeline
- 2008
Google App Engine preview runs apps without managed servers
- 2012
Ken Fromm’s ReadWrite essay describes a “serverless world”
- 2014
AWS Lambda introduces event-driven functions billed per 100 ms
- 2016
Microsoft announces Azure Functions
- 2017
Cloudflare Workers runs functions at the edge in V8 isolates
- 2019
Berkeley paper on serverless computing; Google launches Cloud Run
- 2025
Lambda durable functions add long-running, checkpointed workflows
- Ken Fromm: Why the future of software and apps is serverless (ReadWrite, 2012)
- AWS News Blog: AWS Lambda, run code in the cloud (Nov 2014)
- Azure Blog: Introducing Azure Functions (Mar 2016)
- Jonas et al.: Cloud Programming Simplified, a Berkeley View on Serverless Computing (2019)
- Cloudflare Blog: Cloud computing without containers (2018)
- Google App Engine docs: What is Google App Engine? (2008) · archived copy, original
- Google Cloud Blog: Cloud Functions is generally available (Aug 2018)
- Google Cloud Blog: Announcing Cloud Run (Apr 2019)
- AWS What’s New: Lambda durable functions (Dec 2025)
Sources11
- Lambda docs: Quotas (15-minute timeout)
- Lambda docs: Execution environment lifecycle (cold starts)
- Lambda docs: Event source mappings
- AWS Lambda pricing (per request and per millisecond)
- Cloud Run docs: Cloud Run functions comparison
- Azure docs: Azure Functions overview
- OpenFaaS docs
- Knative docs
- Cloudflare Workers docs
- Fission docs: Concepts
- beam-cloud/beta9 on GitHub (AGPL-3.0)