FaaS: Run Code, Not Servers

WHY IT EXISTS: Before FaaS, even a small, infrequently run task required a server (physical or virtual) that you had to provision, patch, scale, and pay for 24/7. FaaS was created to eliminate this operational overhead and wasted cost for event-driven workloads, allowing developers to focus purely on business logic.

THE MENTAL MODEL: Think of FaaS not as renting a server, but as renting execution time. You provide a piece of code (a function) and tell the cloud provider, "Run this only when X happens." The provider handles finding a machine, running the code in a temporary environment, and then tearing everything down. You only pay for the milliseconds your code is actually running.

HOW IT WORKS: You upload your code as a self-contained function and configure a trigger, which is an event that will cause it to execute. Triggers can be an HTTP request, a new file in a storage bucket, a message in a queue, or a scheduled time. When the trigger fires, the FaaS platform instantly provisions a container, loads your code, executes it with the event data as input, and then shuts the container down. The platform manages all scaling automatically.

WHEN TO USE IT: FaaS is ideal for stateless, short-lived, event-driven tasks. Good examples include: building API backends for single-page applications, processing data streams, running scheduled cron jobs, and creating "glue code" between different cloud services. It excels with unpredictable or "spiky" traffic patterns where resources can scale from zero to thousands and back down.

WHEN NOT TO USE IT: Avoid FaaS for long-running, stateful applications or tasks with constant, high-throughput workloads. The "cold start" latency (the time to provision a new container for the first time) can be an issue for applications requiring immediate, low-latency responses. For sustained traffic, the pay-per-invocation model can become more expensive than a dedicated server or container running 24/7.

ONE CANONICAL EXAMPLE: A user uploads a profile picture to your app's cloud storage bucket. The upload event triggers a FaaS function. This function takes the newly uploaded image, generates three different thumbnail sizes (small, medium, large), and saves them back into the storage bucket. The entire process happens automatically without any server to manage, and you only pay for the few hundred milliseconds of compute time the image resizing took.