Local is the workshop; production is the storefront. But the storefront does not need a clerk standing idle all night waiting for a customer who may never come. Sometimes the right model is: nobody on duty, and the moment a visitor arrives, someone appears, handles exactly that visit, and leaves. That is serverless.

What "serverless" actually means

A serverless function is small hosted code that runs when a platform receives a request, an event, or a schedule tick. The honest first sentence: servers still exist. The platform owns them, keeps them patched, and decides how many copies of your code to run. You never rent a computer, never SSH in, never restart a process. You hand the platform a function — "when this happens, do that" — and it executes your code on demand and scales it up or down by itself.

Compare that with the VPS from Class 24. A VPS is an apartment you rent and operate: always on, always costing, yours to maintain whether or not anyone visits. Serverless is a food stall that materializes when a customer walks up, serves one order, and vanishes. Idle time costs you nothing because there is no idle computer with your name on it.

The request path, step by step

Trace one visitor through the system:

visitor (browser / API call / webhook)
  → platform receives the request and starts your function
    → function reads data / calls a service
      → function returns a response
        → execution ends, platform reclaims the resources

Every step matters. The function does not exist before the request — the platform starts it. It does its job — reads cached facts from Postgres, calls a model only when needed, formats the page. It returns the response. Then it ends. The database rows persist; the function does not. If ten visitors arrive at once, the platform starts ten copies. When nobody visits, zero copies run and you pay for zero execution.

Two current examples to anchor the idea: Vercel Functions, where a file in your project becomes an HTTP endpoint that deploys alongside your frontend, and Cloudflare Workers, where your code runs close to the network edge in many locations at once. Link to their docs when you need current behavior — the durable concept is "platform runs short code on trigger," not any one dashboard.

Where serverless fits well

Reach for a function when the work is request-driven: a discrete unit of work with a clear trigger, a short duration, and a response someone is waiting for.

• API endpoints. "Give me the research page for this company" — read the database, return JSON.
• Form handlers. A visitor submits a source suggestion; the function validates it, stores it, and confirms.
• Lightweight transformations. Resize an avatar, convert Markdown to HTML, reformat a feed.
• Webhook receivers. Accept the incoming event, verify it, record it, and queue anything slow (webhooks get their full treatment in Class 27).
• Small scheduled checks. Ping a source once an hour and record whether it changed — the alarm-clock pattern Class 26 will expand.

The worked example: a user requests a company research page. The function wakes, reads cached facts from Postgres, calls a model only if the cached summary is stale or missing, returns the page, and ends. No server sat idle all day waiting for that one request. Multiply by a thousand requests and the platform simply ran the function a thousand times.

The constraints — learn these before you commit

Serverless removes operations by imposing limits. Know all four before recommending it:

1. Execution time limits. Functions must finish quickly — seconds to low minutes depending on the platform and plan. A job that takes twenty minutes does not belong here. 2. Stateless runtime assumptions. The function cannot keep anything in its own memory between runs. Each execution starts fresh. Anything durable — session state, uploaded bytes, job progress — must live somewhere else: a database, object storage, a queue. 3. Provider-specific limits. Memory size, payload size, concurrent executions, bandwidth — every platform draws lines. They change over time, so check the docs rather than memorizing numbers. 4. Durable work lives elsewhere. A function that needs retries, ordering, or guaranteed delivery needs a queue and a worker behind it, not mere hope. The function is the front door, not the whole building.

Practical exercise: classify three request-driven features

Pick three features from your own project that could be request-driven. For each, write one card with four lines:

• Input: what arrives (URL parameter, form fields, webhook payload)?
• Output: what returns (page, JSON, confirmation)?
• Maximum acceptable wait: how long may the visitor wait — 2 seconds? 10? What happens past that?
• Durable data store: where do the lasting results live (which Postgres tables, which storage bucket)?

Example shape, using the research page: *Input: company slug from URL. Output: rendered page with cached facts and citations. Max wait: 5 seconds, then show cached version with a staleness note. Store: companies, facts, and source_links tables in Postgres.*

Finish line: three cards, each with input, output, max wait, and named store — written down, not in your head.

Verify: for each card, point to the store line and ask: "If the function runs twice, does anything duplicate?" If you cannot answer, the durable side is underspecified — Class 26 will give you the tools.

Common failure mode: stuffing a ten-minute report generation into a function because "serverless scales." It times out halfway, the user sees an error, and the half-written result sits in the database. Long work belongs in a queued background job; the function should only accept the request and hand it off.

Check your understanding

1. If servers still exist, what does "serverless" actually spare you from doing? 2. Trace the five steps of the request path without looking back. 3. Name the four constraints that disqualify a workload from a plain function. 4. Why must a function treat its own memory as disposable?