Function as a Service (FaaS) is a cloud computing model in which you upload small, self-contained pieces of code, called functions, and the provider runs them when an event triggers them, such as a web request, a file upload, a message on a queue or a schedule. The provider handles the servers, operating systems, scaling and patching, and bills mainly for the number of runs and the time and memory each one uses. FaaS is the best-known part of serverless computing and is offered by the major public clouds and by some edge and content delivery platforms.
At a glance
- You deploy code and define its triggers; the provider runs it in short-lived, isolated environments.
- Capacity scales up and down automatically with demand, within limits the provider sets.
- Billing is mainly per invocation and per unit of execution time and memory, so idle code costs little or nothing unless you reserve warm capacity.
- Functions are designed to be stateless; data that must persist lives in databases, storage or caches.
- Trade-offs include start-up delays after idle periods, run-time limits, provider-specific triggers and harder debugging across many small pieces.
What problem it solves
Plenty of software work is small and intermittent: resizing an uploaded image, processing a webhook from a SaaS application, running a nightly report, or responding to an API call that arrives a few hundred times a day. Running a server for each job means paying for idle capacity and patching, monitoring and scaling machines that do little most of the time.
FaaS lets developers write just the code that handles the event and leave everything underneath to the provider. Teams avoid managing servers for these jobs, pay mostly in proportion to use, and can handle sudden traffic spikes without capacity planning, which suits event-driven and microservices designs.
How it works
- Write and deploy. A developer packages a function in a supported language, or as a container image on some platforms, along with its settings such as memory and timeout.
- Define triggers. The function is connected to events: an HTTP endpoint, a change in storage or a database, a message queue, a stream or a timer.
- Execute on demand. When an event arrives, the platform runs the function in an isolated environment. Providers implement this differently, using containers, lightweight virtual machines or other sandboxes.
- Scale automatically. More simultaneous events mean more simultaneous copies of the function, up to account or regional concurrency limits.
- Bill and log. Each run is metered, and logs and metrics go to the provider’s monitoring tools or to your own observability platform.
Functions that haven’t run recently may suffer a “cold start” delay while a new environment starts. Providers offer ways to keep capacity warm, usually for a standing fee.
When it matters for buyers
- When modernizing applications. FaaS fits event-driven pieces such as integrations, data processing steps and APIs with variable traffic, rather than every workload.
- When cloud bills include idle servers. Moving intermittent jobs to functions can cut waste, but steady high-volume workloads may cost more as functions.
- When latency matters. Cold starts and network hops can affect user-facing performance; edge function platforms run code closer to users.
- When assessing lock-in. Triggers, permissions and surrounding managed services tie applications to a provider more than the function code does.
- When operating at scale. Many small functions need consistent logging, tracing, permissions and deployment practices to stay manageable.
Most organizations use FaaS through their public cloud provider; edge platforms offer similar functions closer to users.
Questions to ask vendors
- What concurrency, memory, payload and run-time limits apply, and can they be raised?
- How are invocations, execution time and data transfer priced, and what do warm-capacity options cost?
- What are typical cold-start times for our language and package size?
- Which event sources are supported, and which are specific to your platform?
- How do logging, tracing and alerting work across many functions?
- Which regions and data residency options are available?
How it differs from PaaS and containers
Platform as a service (PaaS) runs whole applications for you: you deploy an app, and it typically stays running, often with a minimum number of instances you pay for. FaaS runs individual functions only when events arrive and can scale to zero. Containers package an application and its dependencies to run anywhere, but you or a managed service still decide how many run and for how long, usually with container management tools; they suit long-running services and give more control over the runtime. FaaS trades that control for less operational work. Many applications combine all three, and some platforms now run containers on a per-request basis, blurring the lines.