On this page
Definition
Serverless computing is a cloud model where a provider manages the servers automatically, running application code on demand and billing based on actual usage rather than pre-allocated capacity.
Simple explanation
Despite the name, servers are still involved — you simply do not have to provision, patch or scale them yourself. You write a small piece of code called a function, and the cloud provider runs it only when it is triggered, such as by an HTTP request or a scheduled event.
If nobody uses your function for a while, it costs nothing and uses no resources. If demand suddenly spikes, the provider automatically runs many copies in parallel, without you configuring anything in advance.
Why it matters
Serverless removes a large chunk of operational work — no server patching, no capacity planning, no idle infrastructure sitting around waiting for traffic. That lets small teams run infrastructure that would previously have needed a dedicated ops function.
It also aligns cost directly with usage, which can be far cheaper for spiky or unpredictable workloads than running always-on servers.
How it works
- 1WriteA developer writes a function that handles a specific task or request.
- 2DeployThe function is uploaded to a cloud provider's serverless platform.
- 3TriggerAn event — an HTTP request, file upload or schedule — invokes the function.
- 4ScaleThe provider runs as many instances as needed, automatically, in parallel.
- 5BillYou are charged only for the compute time actually consumed.
Real examples
Products named for illustration only. Inclusion is not an endorsement.
- AWS LambdaThe original mainstream serverless compute platform.
- Vercel FunctionsServerless functions bundled with frontend deployments.
- Cloudflare WorkersRuns serverless code at edge locations close to users.
- Google Cloud FunctionsGoogle's equivalent event-driven serverless platform.
Advantages
- No server management, patching or capacity planning required.
- Cost scales directly with actual usage rather than idle capacity.
- Automatically handles sudden spikes in traffic.
- Lets small teams ship backend functionality without dedicated infrastructure staff.
Limitations
- Cold starts can add latency for functions that have not run recently.
- Long-running or highly stateful workloads are a poor fit.
- Vendor lock-in risk, since serverless platforms differ in their APIs and limits.
- Debugging and monitoring distributed functions can be harder than a single server.
Common misunderstandings
- ClaimServerless means there are no servers at all.RealityServers still run the code — the provider simply manages them so you do not have to.
- ClaimServerless is always cheaper than traditional hosting.RealityIt is cost-effective for spiky or low-traffic workloads, but can be more expensive than a dedicated server under sustained heavy load.
Frequently asked questions
Is serverless the same as cloud hosting?
It is a specific model of cloud hosting where the provider manages scaling and server operation entirely.
What is a 'cold start'?
A brief delay that occurs when a serverless function is invoked after being idle and needs to initialise.
Can serverless run any application?
It suits short-lived, event-driven tasks best; long-running or highly stateful applications are usually a poor fit.
Do I still need to write code for serverless?
Yes, you write the same application logic — serverless changes how it is deployed and run, not how it is written.
Is serverless good for startups?
It is often a good fit, since it avoids upfront infrastructure investment and scales automatically with early, unpredictable demand.
The Tool Money Lab perspective
Serverless has genuinely lowered the barrier to running backend infrastructure, letting small teams ship features that once required a dedicated platform engineer.
We caution against assuming serverless is automatically cheaper — for consistently high-traffic workloads, a well-managed traditional server or container setup can still work out more cost-effective.
Conclusion
Serverless shifts the burden of server management to the cloud provider, letting developers focus on code that runs on demand and scales automatically.
It is not the right fit for every workload, but for event-driven, spiky or early-stage applications, it removes a significant amount of operational overhead.