Serverless

Serverless computing is a cloud execution model where the developer writes and deploys individual functions (or small services), and the cloud provider handles all the underlying server provisioning, scaling, and infrastructure management — the servers still physically exist, but the developer never sees, configures, or pays for idle capacity on them. The dominant form is Function-as-a-Service (FaaS): AWS Lambda, Google Cloud Functions, Azure Functions, and Cloudflare Workers all let you deploy a single function that runs in response to a trigger (an HTTP request, a file upload, a queue message) and scales from zero to thousands of concurrent invocations automatically, billed per invocation and execution time rather than per hour of a running server. Why it matters for AI/SaaS builders: serverless removes a huge category of ops work (capacity planning, patching, scaling policies) and its pay-per-use pricing is extremely attractive for spiky or low-traffic workloads — a webhook handler that fires occasionally costs almost nothing on serverless versus paying for an always-on server. The trade-offs are cold-start latency (a function that hasn't run recently takes longer on its first invocation while the provider spins up an execution environment), statelessness (you can't rely on in-memory state persisting between invocations — durable state must live in an external database or cache), and execution time limits (most FaaS platforms cap a single invocation at a few minutes to 15 minutes). How it works: you deploy a function's code plus a manifest describing its trigger and resource limits (memory, timeout). The provider's infrastructure listens for that trigger, and on each event, spins up (or reuses a "warm") execution environment, runs your function with the event data as input, captures the return value/response, and tears down or recycles the environment. Concurrency is handled automatically — 1,000 simultaneous requests spin up (up to) 1,000 parallel function instances without the developer configuring an auto-scaling group. Worked example: a SaaS product needs to resize a user's uploaded avatar image whenever one is uploaded. Instead of running a dedicated always-on image-processing server, they deploy an AWS Lambda function triggered by S3 object-creation events. When a user uploads `avatar.jpg` to the S3 bucket, S3 automatically invokes the Lambda function with the object's key; the function downloads the image, resizes it to three thumbnail sizes using a library like Sharp, uploads the resized versions back to S3, and exits — the whole thing runs in under a second, costs a fraction of a cent, and the team never provisioned or manages a single server for this feature.