You hand a function to the platform; it scales from zero to thousands of concurrent invocations on demand and bills you per request and per ms of execution. There are servers — they're just not yours to patch, scale, or wake up at 3 a.m. for. The trade-off is a tightly constrained execution model.
← Back to ArchitectureNo OS patches. No autoscaling groups. No fleet rotation for security CVEs. The platform runs everything; you write business logic.
If you're idle 23 hours a day and slammed for one, a serverless function pays for the busy hour and nothing for the rest. Compared to a always-on EC2 instance, it can be 10–100× cheaper.
Each function is its own deployable. Roll out, roll back, version, alias — all per function. Trial a fix on 5% of traffic; promote if metrics hold.
The cloud provider's event sources wire directly to functions: S3 upload → Lambda; new row in DynamoDB → Lambda; queue message → Lambda; cron → Lambda. Glue work that would take a service in microservices is one config block here.
The first request after idle time pays for spinning up a fresh container. Latency: ~10ms (Cloudflare V8 isolates) to several seconds (Java on Lambda with a fat dependency tree). For latency-sensitive APIs, mitigate with provisioned concurrency, smaller bundles, or warm-up pings — or pick a different style.
Each function instance opens its own connection. Scale to 1,000 concurrent invocations and your Postgres collapses. Front the DB with a pooler (RDS Proxy, PgBouncer, Supabase) or use HTTP-native datastores (DynamoDB, Firestore, PlanetScale's edge driver).
You can't keep an in-memory cache, a websocket connection, or a long-running session in the function. Push state to Redis, Durable Objects, or a database. Even "warm" instances can be killed at any moment.
Function signatures, event shapes, IAM, observability tooling — all platform-specific. Lambda code doesn't run on Cloud Functions without rewrites. Frameworks like Serverless Framework, SST, and OpenFaaS reduce this but don't eliminate it.
Reproducing the cloud event shape and IAM context on your laptop is awkward. Tools (LocalStack, SAM, SST live mode) help but don't match production exactly. Distributed traces are essential — without them, debugging multi-function flows is guesswork.
Cloud Run, AWS App Runner, Azure Container Apps, Fargate. Bring a container, get scale-to-zero and per-request billing without function-style constraints. Same image runs locally and in prod. The middle ground between FaaS and Kubernetes.
Cloudflare Workers, Vercel Edge, Lambda@Edge. Code runs in PoPs close to the user — single-digit-ms latency. Constrained runtimes (V8 isolates, no Node-native modules) but the cold start is near-zero. Sweet spot: auth, A/B routing, personalization, geolocation, image transforms.
Orchestrate multiple functions into durable workflows that survive crashes and run for days. AWS Step Functions, Google Workflows, Temporal, Azure Durable Functions. Used for sagas, ETL, long-running approvals.
| Workload | Serverless Fit |
|---|---|
| Webhooks, integrations | Excellent — bursty, stateless, short. |
| Scheduled jobs / cron | Excellent — pay only when running. |
| Image / file processing on upload | Excellent — event-driven by nature. |
| Low-traffic APIs & admin tools | Great — scale-to-zero saves money. |
| BFF / API gateway logic | Great — especially at the edge. |
| High-throughput latency-sensitive APIs | Iffy — cold starts hurt; cost surprises at scale. |
| Long-running jobs (>15 min) | No — use containers or Step Functions. |
| Heavy in-memory state, ML inference | No — package limits, cold starts, GPU access. |
| WebSockets, persistent connections | Use specialized runtimes (API Gateway WebSockets, Durable Objects). |