Cloud Service Model · 4 of 6

FaaS / Serverless

Write a function. The cloud runs it on demand, scales it from zero to thousands per second, and charges only when it's actually executing. The most "cloud-native" of all the models.

FunctionsEvent-drivenPay-per-executionScale-to-zeroNo servers
← Back to Cloud
Quick Facts

At a Glance

Basic Concepts

  • Function: a small piece of code with a defined trigger (HTTP, queue, schedule, event).
  • Stateless & ephemeral — the runtime appears, runs, disappears.
  • Cold start: the latency penalty when a new container spins up.
  • Pay per request & per millisecond of execution.
  • "Serverless" is broader than "FaaS" — also includes serverless DBs, queues, search, etc.
Landscape

The Major Platforms

PlatformNotes
AWS LambdaThe original; broadest trigger ecosystem.
Azure FunctionsMultiple plans (Consumption, Premium, Flex).
Google Cloud Functions / Cloud Run FunctionsCloud Run is the modern recommended path.
Cloudflare WorkersV8 isolates, sub-ms cold starts, edge global.
Vercel FunctionsEdge & serverless functions tied to Next.js deploys.
Netlify FunctionsSame idea, Netlify-native.
Deno DeployDeno-native edge runtime.
Fastly ComputeWASM at the edge.
Modal / Beam / BananaServerless GPUs for AI workloads.
Mechanics

How FaaS Works

The Execution Model
  1. A trigger fires (HTTP request, queue message, S3 upload, cron tick).
  2. The platform finds (or starts) an instance of your function.
  3. Your code runs to completion or timeout (typically 15 min max).
  4. The instance may stay "warm" for a few minutes for the next call.
  5. You're billed for invocation count + GB-seconds of memory × runtime.
Triggers — Way More Than HTTP
  • HTTP / API Gateway — REST endpoints.
  • Queues (SQS, Service Bus, Pub/Sub) — process messages.
  • Streams (Kinesis, Event Hubs, Kafka) — real-time data.
  • Storage events — "new object in S3" → resize image.
  • Database changes — DynamoDB streams, Cosmos DB change feed.
  • Cron / schedules — nightly jobs without a server.
  • IoT events, webhooks, auth events…
Cold Starts & Mitigations

The biggest pain. Mitigations:

  • Provisioned concurrency — keep N instances warm (defeats some cost benefit).
  • Lighter runtimes — Go, Rust, Node beat heavy JVM cold starts.
  • SnapStart / AOT — pre-init the runtime image (Lambda SnapStart, GraalVM native).
  • Edge runtimes (Workers, Vercel Edge) use V8 isolates — < 1ms.
  • Keep dependencies minimal — small bundles cold-start faster.
Limits & Constraints
LimitTypical value
Max execution time15 min (Lambda); 60 min (Cloud Run); 30s (edge)
Max memory10 GB (Lambda)
Max payload6 MB sync, 256 KB async
Concurrency / region1000 default (raise on request)
Local disk (ephemeral)512 MB – 10 GB (/tmp)
Code package size50 MB zipped, 250 MB unzipped
Patterns
  • API backend — small CRUD APIs behind API Gateway.
  • Queue processor — fan-out work without managing workers.
  • Webhook receivers — handle GitHub, Stripe, Slack events.
  • Image / media processing — on upload to object storage.
  • Scheduled tasks — replace cron servers.
  • Glue between services — small transformations, retries, ETL.
  • Edge personalization — A/B, geo, auth checks at the CDN.
Trade-offs

Strengths & Weaknesses

Strengths
  • Pay only when running — pennies for low traffic.
  • Auto-scales to thousands instantly.
  • No infra to patch or monitor.
  • Massive trigger ecosystem encourages event-driven design.
Weaknesses
  • Cold starts hurt user-facing latency.
  • Hard to reproduce locally (vendor specifics).
  • Stateless model rules out long-lived connections (WebSockets need workarounds).
  • Cost can balloon at sustained high traffic — containers may be cheaper.
When to Use

Sweet Spots

Bursty / Spiky Workloads

Sporadic webhooks, jobs that run a few times a day.

Event-Driven Pipelines

S3 trigger → resize → save → notify.

Edge Personalization

Auth, A/B, redirect logic at the CDN.

Glue & Automation

SaaS-to-SaaS workflows, slack bots, ChatOps.

Continue

Other Service Models

IaaSPaaSSaaSDBaaSContainers as a Service ↑ Back to Cloud