Serverless

What it is

Serverless means you write individual functions and the cloud provider runs them only when something triggers them — an HTTP request, a file upload, a scheduled timer. There are still servers underneath, but you never see or manage them. You pay only for the time your code actually runs, often down to the millisecond.

Strengths

• No servers to provision, patch, or keep running.
• Scales from zero to thousands of concurrent runs automatically.
• Pay-per-use pricing; idle code costs nothing.
• Integrates cleanly with cloud events (queues, storage, databases).
• Good fit for bursty or unpredictable traffic.

Trade-offs

• Cold starts: a function that hasn't run recently may take extra time to wake up.
• Execution time limits (often a few minutes) rule out long jobs.
• Costs can surprise you at very high, steady volume versus a plain server.
• Local testing and debugging are trickier than a normal app.
• Vendor lock-in — each provider's event model and APIs differ.

When to use it

Pick serverless for APIs, webhooks, scheduled jobs, and event-driven tasks where traffic is uneven and you'd rather not babysit infrastructure. It shines for glue code between cloud services.

Vibe coding fit

Serverless pairs well with AI-directed development because the unit of work is a single, self-contained function — easy for an agent to generate, test, and deploy. Frameworks like AWS SAM, the Serverless Framework, and Vercel let the AI define the function, its trigger, and permissions in one config file. Tip: ask the agent to set a sensible timeout and memory size explicitly, and to keep dependencies minimal — fewer packages mean smaller bundles and faster cold starts.

# serverless.yml — AWS Lambda function
service: my-api
provider:
  name: aws
  runtime: nodejs20.x
  timeout: 10
functions:
  hello:
    handler: handler.hello
    events:
      - httpApi:
          path: /hello
          method: get

# Deploy the stack
npx serverless deploy