Mirco Cloud Primer
Photo by emre varışlı on Pexels
Despite the name, servers are absolutely still involved in serverless computing. Nobody has invented software that runs on nothing. What's actually "server-less" is your relationship with those servers: you never provision one, never patch one, and never even know which physical machine ran your code. It's a bit like using a vending machine instead of hiring staff to run a small shop — the inventory and mechanics are all still there, just completely hidden from the person pressing the button.
This article explains what serverless computing really means, how it differs from the other cloud service models, and where it tends to shine or struggle.
What "Serverless" Actually Means
Serverless computing is a way of running code where the cloud provider automatically handles all server provisioning, scaling, and maintenance, and you're billed only for the actual computing time your code consumes. You write a piece of code — often called a cloud function — attach it to a trigger, such as a file upload or an incoming web request, and the provider takes care of running it whenever that trigger fires.
There's no server to leave running around the clock. If nothing triggers your code, nothing runs, and nothing is billed beyond perhaps a small amount of storage for the code itself.
How It Differs From the Other Service Models
| Model | What you manage | How you're billed |
|---|---|---|
| IaaS | Operating system, runtime, and application, on rented infrastructure | Usually by time the infrastructure is reserved or running |
| PaaS | Your application code on a managed, continuously running platform | Usually by time the application is deployed and running |
| Serverless | Just the code for individual functions or tasks | Usually by actual execution time and number of invocations |
Serverless computing is often described as an evolution beyond PaaS: instead of keeping an entire application running continuously, the provider spins up tiny, temporary execution environments only when needed, then shuts them down.
The Vending Machine Analogy, Extended
A staffed shop (think IaaS or PaaS) keeps someone on the clock whether customers are walking in or not. A vending machine (serverless) sits dormant, consuming almost nothing, until someone presses a button — then it springs into action for a few seconds and goes quiet again. This matches how serverless billing usually works: you pay for the moments your code actually executes, not for idle time in between.
Why Teams Choose Serverless Computing
- No server management at all. There's nothing to patch, resize, or monitor at the operating-system level.
- Automatic, built-in scaling. If a trigger fires a thousand times at once, the provider runs a thousand instances of your code without you configuring anything, a more hands-off version of auto-scaling.
- Pay only for what runs. Idle periods generally cost little to nothing, which fits sporadic or unpredictable workloads well.
Where Serverless Computing Struggles
- Cold starts. When code hasn't run recently, the provider needs a moment to prepare an environment, adding a small delay before execution begins.
- Execution time limits. Serverless functions are usually designed for short-lived tasks, not long-running processes.
- Less visibility and control. Troubleshooting can be trickier when you can't directly inspect the underlying environment.
- Not ideal for constant, heavy workloads. A workload that runs nonstop may be handled more predictably by continuously running infrastructure or a platform.
Typical Things People Build With Serverless Computing
- Resizing an image automatically the moment it's uploaded to storage
- Responding to a single, infrequent web request, such as a contact form submission
- Running a short scheduled task, like a nightly cleanup job
- Reacting to an event elsewhere in a system, such as a new database entry
A Closer Look at the Billing Model
Traditional infrastructure, even idle, usually keeps costing money because it's reserved and running regardless of whether anyone is using it. Serverless computing flips this: if your trigger never fires in a given hour, day, or month, you typically owe nothing beyond perhaps a tiny storage fee for the code itself. This article won't put specific numbers on that difference, but the underlying principle matters for understanding why serverless appeals to projects with bursty, unpredictable, or rarely used functionality — the billing follows actual use far more closely than with infrastructure that has to sit ready at all times.
Common Mistakes Beginners Make
- Expecting serverless to mean "no infrastructure thinking required." You still need to design your code around triggers, limits, and cold starts.
- Using it for long-running, continuous processes. Serverless platforms usually aren't built for tasks that run nonstop for hours.
- Ignoring cold-start delays for latency-sensitive features. A noticeable pause on the first request can surprise users if it isn't planned for.
- Assuming it's automatically the cheapest option. Cost depends heavily on usage patterns, not the model itself.
Frequently asked questions
If serverless still uses servers, why is it called that?
The name refers to your experience, not reality. Servers absolutely exist behind the scenes, but the provider manages them so completely that you never need to think about, configure, or even know which server is running your code.
Is serverless the same thing as a cloud function?
A cloud function is the most common way to use serverless computing, but serverless computing also covers other on-demand services, such as some databases and messaging systems, that scale and bill themselves without you managing servers.
Is serverless always cheaper than running a server continuously?
It depends entirely on your usage pattern, and this article doesn't compare specific prices. As a general concept, serverless billing is usage-based, which tends to suit sporadic or unpredictable workloads better than constant, heavy ones.
What's a cold start, and why does it matter?
A cold start is the brief delay that happens when serverless code runs after sitting idle, because the provider has to prepare an environment for it first. For latency-sensitive applications, this delay is worth understanding before you rely on serverless computing.
Related reading
Sources
- NIST SP 800-145 — The NIST Definition of Cloud Computing
- Documentation published by major public cloud providers (consulted October 2026)