What Is Serverless?
Serverless is a cloud model where your backend code runs as on-demand functions — you don't provision or manage servers, and you pay per invocation rather than per idle server-hour.
Serverless is a cloud execution model where your backend code runs as on-demand functions that the platform starts, scales, and shuts down for you. You don't provision or manage servers, and you pay per invocation and execution time rather than per idle server-hour.
The name is misleading: there are still servers. You just never touch them. Your code is packaged as a function, uploaded to a cloud platform, and run only when something triggers it. The platform handles scaling, redundancy, and uptime automatically.
How serverless works
A serverless function follows the same lifecycle on every platform:
- A trigger fires — an HTTP request, a scheduled cron, a database change, a queue message, or an auth event.
- The platform allocates compute, loads your function, and runs it.
- The function returns a response and the platform tears the instance down.
- You're billed for execution time and invocation count — not for the hours the function sat idle.
Concurrency is automatic. If one request arrives, one instance runs. If 1,000 arrive at once, the platform spins up roughly 1,000 instances in parallel, then scales back to zero when traffic stops. You write the function; the platform owns the capacity math.
Serverless vs. a traditional server
| Serverless function | Traditional server / container | |
|---|---|---|
| Scaling | Automatic, per-request, down to zero | Manual or autoscaling groups you configure |
| Billing | Per invocation + execution time | Per running hour, idle or not |
| State | Stateless between invocations | Can hold in-memory state |
| Runtime limit | Capped (often 10–60s) | Unbounded |
| Ops burden | Platform handles it | You patch, monitor, and scale |
| Best for | Spiky or unpredictable traffic, APIs, glue logic | Steady load, long jobs, persistent connections |
Where serverless fits a SaaS MVP
Serverless is a common default for new SaaS backends because the operational overhead is near zero until you have real traffic. Vercel deploys Next.js API routes as serverless functions automatically. Supabase Edge Functions run Deno code close to the database. You get a production-grade backend with no server to patch and near-zero cost while you're still finding product-market fit.
A concrete shape: a booking app handles a POST /reservations request as a serverless function — it validates the payload, writes a row to the database, calls a payment API, and sends a confirmation email, then exits. Nothing runs between bookings, so an app with bursty, unpredictable traffic pays only for the requests it actually serves.
Trade-offs to plan for
- Cold starts — the first invocation after an idle period takes longer (commonly ~50–500ms, language- and platform-dependent) because the runtime has to initialize. Warm invocations are fast.
- Stateless by design — there's no reliable in-memory state between calls. Push shared state to a database, Redis, or object storage.
- Execution limits — most platforms cap a single function's runtime (often 10–60 seconds), so a 5-minute job needs a different approach.
- Vendor specifics — triggers, limits, and bundling differ per platform, which couples your deployment to that platform's conventions.
When NOT to use serverless
Reach for a dedicated server or long-running container when the workload fights the model:
- Long-running background jobs that exceed the runtime cap (large exports, video processing).
- Persistent connections like WebSockets or long-poll streams that expect a process to stay alive.
- CPU- or memory-heavy compute where per-invocation billing and cold starts cost more than a steadily-running box.
- Steady, predictable, high traffic — at constant high load, a reserved server is often cheaper than per-invocation pricing.
Common mistakes
- Treating functions as stateful — caching data in a module-level variable and assuming it survives. It may, by luck, on a warm instance — then vanishes on the next cold start.
- Ignoring cold starts on user-facing paths — putting a rarely-hit, latency-sensitive endpoint on serverless without warming or accepting the first-hit delay.
- Opening a fresh database connection per invocation — at high concurrency this exhausts the connection pool. Use a pooler or a serverless-friendly driver.
- Forcing a long job into the runtime limit — splitting work across a queue, or moving it to a container, instead of fighting the timeout.
Key takeaways
- Serverless means someone else runs the servers; you ship functions and pay only when they execute.
- It scales automatically from zero, which makes it a strong fit for spiky traffic and early-stage products.
- Watch for cold starts, statelessness, and runtime caps — they decide whether a workload belongs on serverless at all.
- For long jobs, persistent connections, or steady heavy load, a traditional server or container is usually the better call.
Weighing serverless against a managed server for your own product? Contact for a quote to talk through the architecture.