Function-as-a-Service, or FaaS, is the compute side of serverless. Instead of deploying a long-running server process, a developer uploads individual functions, and the platform runs each one on demand in response to an event such as an HTTP request, a file upload, or a queue message. The 2019 Berkeley paper “Cloud Programming Simplified: A Berkeley View on Serverless Computing” treats serverless compute as code that the cloud provider runs and scales while handling the underlying system administration on the developer’s behalf.
AWS Lambda, launched in preview on November 13, 2014, was the service that brought this model into the mainstream. The launch post “AWS Lambda - Run Code in the Cloud” described running code automatically in response to events with no server management or capacity planning. Microsoft Azure Functions, Google Cloud Functions, and Cloudflare Workers later offered the same shape: write a function, declare its triggers, and let the platform handle execution and scaling.
The defining characteristic of FaaS is that each function scales independently. If a single function receives a burst of events, the platform spins up additional execution environments just for that function, and tears them down when the burst subsides. Because functions are stateless and short-lived, they fit naturally with event-driven and microservice architectures.
This independence is also FaaS’s main constraint. Functions cannot rely on local state persisting between invocations, and the first request to a newly created execution environment incurs a startup penalty known as a cold start. These trade-offs shape how serverless applications are designed.