On this page
What Is Serverless Computing?
Serverless runs your code on demand without managing servers, billing only for execution. Learn the model, cold starts, and when it fits.
Quick answer
- Serverless lets you run code without provisioning or managing servers; the provider runs it on demand.
- You pay only for execution time, so idle apps cost almost nothing.
- The trade-offs are cold starts and less control over the runtime.
What is serverless computing?
Serverless computing is a cloud model in which the provider runs your code and manages the servers, so you write and deploy functions without provisioning infrastructure. The name is slightly misleading — servers still exist, you just don’t operate them. Functions as a service (FaaS) such as AWS Lambda is the most common form, alongside managed services for databases and queues that also bill by usage.
How does it work?
You upload a function — a small unit of code that handles one event, like an HTTP request or a file upload — and configure what triggers it. When the event occurs, the provider allocates resources, runs the function, and releases them. Billing is based on invocations and execution time, so a function that runs rarely costs essentially nothing.
Why does it matter?
Serverless removes capacity planning and idle-cost for bursty, event-driven, or low-traffic workloads. It also shortens time-to-deploy: no cluster, no instance image, just code plus configuration. The flip side is less control, harder local debugging, and the risk of vendor lock-in.
What is a cold start?
When a function has not run recently, the provider must spin up its runtime before executing — a “cold start” that adds latency, from tens of milliseconds to seconds depending on the runtime. Once warm, subsequent calls are fast. Cold starts are the most common surprise for teams moving a latency-sensitive endpoint to serverless.
Where this bites vibecoders
Serverless is genuinely well-suited to a vibecoder’s first API or cron job — tiny, cheap, no server to patch. The gotchas are cold-start latency on user-facing paths and the “billed per millisecond” trap of a function that loops inefficiently. The model rewards small, single-purpose functions, not the monolithic handler an AI assistant may generate by default.
Where AI coding assistants get this wrong
- Bundling a whole app into one giant Lambda handler with slow cold starts.
- Hardcoding secrets in function code instead of the provider’s secret manager.
- Ignoring timeout and memory settings, causing functions to be killed mid-work.
- Generating a serverless design for a steady, always-on workload where a server is cheaper.
Checklist
- Match the model to the workload: bursty and event-driven suits serverless.
- Keep functions small and single-purpose.
- Store secrets in the provider’s secret manager, never in code.
- Set memory and timeout deliberately, and test cold starts.
- Watch invocation counts to avoid billing surprises.
FAQ
Is serverless really “no servers”?
Servers still run your code; you just don’t provision or manage them. The provider handles scaling, patching, and capacity. “Serverless” describes your operational responsibility, not the absence of machines.
What is a cold start?
A cold start is the delay when a function’s runtime must be initialized because it hasn’t run recently. It adds latency to the first request. You can reduce it with smaller runtimes, provisioned concurrency, or keeping functions warm.
Serverless vs containers — which should I use?
Serverless fits sporadic, event-driven, or variable workloads where you want zero idle cost. Containers (and Kubernetes) fit long-running services, predictable load, or when you need control over the runtime. Many systems use both.
Related topics
- How to Deploy Your First Serverless Function on AWS Lambda
- What Are Serverless Cold Starts (and Do They Matter for You)?
- What Is Kubernetes?
- What Is FinOps?
- What Is a Cron Job (and Why Do They Fail Silently)?