Function as a service (FaaS) is a cloud execution model in which developers deploy individual functions, and the provider runs each one only when an event triggers it, scaling instances automatically and billing for the actual execution time and allocated memory. The developer supplies code and configuration; the platform manages servers, operating systems, runtimes and capacity.
In serverless computing, FaaS is the compute building block. It sits alongside managed databases, queues and object storage, which together let teams build applications without operating servers. AWS Lambda, Azure Functions, Google Cloud Run functions and open-source platforms such as Knative and OpenFaaS all implement the model.
How function as a service executes code
A FaaS platform links an event source to a function. When an HTTP request, queue message, file upload or timer fires, the platform finds an idle execution environment for that function or creates a new one, passes the event payload to the handler and returns or forwards the result.
Each environment is an isolated sandbox, often a lightweight microVM or container, holding the runtime and the deployed code. After a call ends, the platform keeps the environment warm for a period so later calls can reuse it. When no environment is free, a new one starts, which is called a cold start.
The following table describes the parts that participate in every invocation.
| Component | Role | Managed by |
|---|---|---|
| Trigger | Emits the event that starts a call | Provider or user service |
| Handler | Function entry point that receives the event | Developer |
| Runtime | Language environment such as Node.js, Python or Java | Provider |
| Execution environment | Isolated sandbox reused across calls | Provider |
| Concurrency controller | Adds or removes environments with load | Provider |
Key parameters and limits
FaaS functions are configured through a small set of parameters, and their limits shape which workloads fit. Exact values differ by provider and change over time, so the ranges below are typical orders of magnitude rather than guarantees.
| Parameter | Typical range | What it affects |
|---|---|---|
| Memory allocation | 128 MB to about 10 GB | CPU share, speed and price per second |
| Maximum duration | Seconds up to about 15 minutes for event functions | Suitability for long jobs |
| Concurrency limit | Hundreds to thousands per account and region | Peak throughput and downstream load |
| Package size | Tens of MB zipped, larger as container images | Cold start time and dependencies |
| Billing granularity | 1 ms to 100 ms | Cost of very short calls |
On most platforms CPU scales with memory, so raising memory can shorten execution enough to lower the total cost. Provisioned or minimum instances keep environments warm to remove cold starts, but they are billed even when idle.
FaaS compared with other compute models
FaaS is the most granular point on a spectrum that runs from virtual machines to managed functions. The further a model moves toward FaaS, the less infrastructure the team operates and the less control it keeps over runtime, networking and state.
| Model | Unit of deployment | Scaling | Billing basis |
|---|---|---|---|
| Virtual machine | Whole operating system | Manual or autoscaling groups | Per running instance |
| Containers on orchestrator | Container image | Pod and node autoscaling | Per provisioned node |
| Serverless containers | Container image | Per request, can scale to zero | Per request time |
| Function as a service | Single function | Per event, scales to zero | Per invocation and duration |
Serverless computing is the broader idea; FaaS is its event-driven compute component. Backend as a service, such as managed authentication or databases, complements FaaS but does not run custom code on demand.
When function as a service is the right choice
FaaS fits workloads that are event-driven, short and bursty. It is weaker for steady high traffic, long computation and latency-critical paths where every millisecond counts.
| Workload | Fit | Reason |
|---|---|---|
| Image resizing after upload | Strong | Event per file, short, parallel |
| Webhook and API glue | Strong | Irregular traffic, simple logic |
| Scheduled maintenance tasks | Strong | Runs minutes per day, no idle cost |
| High steady API traffic | Weak | Per-call pricing exceeds reserved capacity |
| Multi-hour batch processing | Poor | Exceeds duration limits |
| Low-latency trading or gaming | Poor | Cold starts add unpredictable delay |
Limitations and common pitfalls
FaaS removes server management but introduces distributed-system problems that teams often underestimate.
- Statelessness: local memory and disk are not durable between calls, so state belongs in external stores.
- At-least-once delivery: many triggers retry on failure, so handlers must be idempotent to avoid duplicate side effects.
- Connection exhaustion: thousands of concurrent functions can overwhelm a relational database without a connection proxy.
- Cold start latency: large packages and JVM or .NET runtimes can add hundreds of milliseconds to several seconds.
- Vendor lock-in: triggers, permissions and event formats are provider specific even when the code is portable.
- Observability gaps: tracing a request across many short functions requires deliberate distributed tracing.
The simple explanation
Function as a service lets a programmer upload one small piece of code and have the cloud run it only when something happens, such as a customer uploading a photo. Nobody needs to rent or look after a server that waits all day.
It works like a taxi instead of a private car. A car costs money even when parked, while a taxi appears when called and is paid only for the ride. The trade-off is that the first taxi may take a moment to arrive, just as a function may need a short start-up time.
How it is used in practice
An online retailer receives product photos from hundreds of suppliers, mostly in large bursts before seasonal sales. The engineering team attaches a function to the object storage bucket: every new upload triggers it, and it creates three resized versions and a compressed web format, then writes metadata to a database.
The function uses 1,024 MB of memory and finishes in about 800 ms per image. On quiet days it runs a few hundred times; during a supplier catalog drop it processes tens of thousands of images within an hour, with the platform adding environments automatically. The team pays nothing while no images arrive and no longer maintains the two always-on servers that previously handled the queue, while making the handler idempotent so retried events never create duplicate files.