Serverless still runs on servers. The name is a small fib that trips up almost everyone on their first day. What actually disappears is your job of looking after those servers. You do not pick a machine size, you do not install patches, you do not keep anything running through the night. You hand the cloud a piece of code and a rule for when to run it, and the provider finds a server, runs your code, then takes the server away the moment it is done. You get billed for the run, not for the waiting. That shift is the whole idea, and once it clicks, a lot of cloud job postings start to make sense.
A porch light that bills by the second
Think of a motion-sensor porch light. It sits dark and costs you nothing. Someone walks up the path, the sensor fires, the light switches on, does its one job, and switches off a few seconds later. You pay only for the seconds it was lit. A normal always-on server is the opposite: a floodlight you leave burning all night just in case a visitor turns up at 3am. Most of the night it lights an empty path and still runs up the bill. Serverless is the motion sensor. Your code stays dark and free until an event wakes it, runs for a few hundred milliseconds, and goes quiet again.
So who deleted the server?
Nobody. The server is still there. AWS, Azure or Google owns it, shares it across thousands of customers, and only charges you for the slices of time your function actually used it. Because the machine is shared and handed out on demand, the provider keeps it busy and passes the saving on. You trade control, since you cannot log into the box, for freedom from babysitting it. For a fresher that is a fair deal: one less thing that can break at 2am because of something you forgot to patch.
Functions as a Service, in plain terms
The flavour of serverless you will meet first is Functions as a Service, usually shortened to FaaS. You write one function, a short block of code that does one thing: resize an uploaded photo, send a welcome email, save a form to a database. You do not write the loop that waits for requests and you do not manage the web server. The platform does that part. You only say what should happen and what sets it off.
What sets it off
A trigger is the event that runs your function. Common ones: an HTTP request hits a URL, a file lands in storage, a message arrives on a queue, or a timer fires every five minutes. One function, one trigger, one job. String a few of these together and you have a working application without ever renting a server you have to keep alive.
Each of the big three has its own FaaS, and the free grants are big enough that learning and small side projects usually cost nothing. The names and limits below were checked against the providers in 2026; the prices apply once you pass the free grant, in standard US regions.
| Provider | Service | Free grant each month | After the free grant |
|---|---|---|---|
| AWS | Lambda | 1M requests + 400,000 GB-seconds | 0.20 USD per million requests + compute |
| Microsoft Azure | Functions (Consumption) | 1M requests + 400,000 GB-seconds | 0.20 USD per million + 0.000016 USD per GB-s |
| Google Cloud | Cloud Run functions | 2M requests + 180,000 vCPU-s + 360,000 GiB-s | 0.40 USD per million requests + compute |
Cold starts, the thing nobody warns you about
This is the one piece worth slowing down on, because it surprises every newcomer and it shows up in interviews. When a function has not run for a while, the platform has nothing ready for it. The first call has to find a server, copy your code onto it, and start the language runtime before your code even begins. That extra wait is a cold start, and it can add anywhere from a few hundred milliseconds to a couple of seconds depending on the language and how much code you ship.
Once that instance is warm, it stays ready for a while, and the next calls answer in milliseconds. So your function feels slow on the first hit after a quiet spell and fast after that. Nothing is broken. The platform is just building the kitchen before it can cook your first order. Smaller code and faster-starting runtimes like Python and Node.js cut the wait; heavier ones like Java and .NET take longer to warm up.
What a serverless bill actually looks like
Serverless billing has two parts: a tiny charge per request, and a charge for compute measured in GB-seconds, which is memory multiplied by run time. The memory part is where people get surprised, because you pay for the memory you reserve whether your code needs it or not. Here is a real calculation you can follow with a phone calculator.
Memory 512 MB (0.5 GB), runs 400 ms each time, called 3 million times in a month.
Requests: 3,000,000 minus the 1,000,000 free = 2,000,000 billable, at 0.20 USD per million = 0.40 USD.
Compute: 0.5 GB times 0.4 seconds times 3,000,000 calls = 600,000 GB-seconds. Subtract the 400,000 free and you bill 200,000 GB-seconds at about 0.00001667 USD each = 3.33 USD.
Total: about 3.73 USD for the month. Three million image resizes for less than a cup of coffee.
Now change one number. Bump memory to 2 GB and the compute line alone jumps to roughly 16 USD, because you pay for reserved memory whether the code uses it or not. Right-sizing memory is the single biggest lever on a serverless bill.
When serverless is the wrong choice
Marketing decks like to say serverless is always cheaper. That is not true, and believing it will burn you. Serverless wins when traffic is spiky or low: a form that gets a few hundred submissions a day, a nightly report, a webhook that fires now and then. The code is idle almost always, so you pay almost nothing. Flip it around. A service running flat out, handling steady heavy traffic every second of every day, never gets to be idle, so the per-request pricing that saved you money at low volume now costs more than simply renting a server that runs all the time.
My rule, after years of building both kinds: reach for serverless first for anything event-driven or bursty, and move to containers or virtual machines once a workload is busy enough that a server would stay near fully used anyway. The break-even point is real. Good engineers run the numbers for their own traffic instead of trusting the slogan on the slide.
On any one provider free tier, create a single HTTP-triggered function that returns the current time. AWS calls it a Lambda with a Function URL, Azure calls it an HTTP trigger, Google calls it a Cloud Run function. Use the in-browser editor so you install nothing on your laptop. Deploy it, then open the URL twice in a row.
How to check it worked: the first call is noticeably slower than the second. That gap is your cold start, live. You just saw the most-discussed quirk of serverless with your own eyes, and it cost nothing.
Serverless is bigger than just functions
Functions are the front door, but the same pay-for-what-you-use idea now covers more of the stack. Serverless databases scale their capacity up and down on their own and bill by the request or by storage, so a quiet table costs almost nothing. Managed queues, object storage and API gateways all follow the same pattern: no server for you to size, a free grant to start, and a bill that tracks real use. The mental model carries straight over. If a managed service scales to near zero when idle and charges by use rather than by the hour, it is serverless in spirit even if the word function never appears.
This matters because real systems mix these pieces. A small app might be an API gateway in front of a function that reads and writes a serverless database, with files landing in object storage that fires a second function. None of it is a machine you log into. You wire the parts together and watch the bill, which is a different skill from racking hardware.
FAQ
Is serverless really server-less?
No. Servers still run your code. You just never see, choose or manage them. The provider owns and shares the machines and bills you only for the time your function runs.
Is Lambda always cheaper than a normal server like EC2?
No. For low or spiky traffic, usually yes. For a service under constant heavy load, a right-sized server or container often wins, because you stop paying a small premium on every single request. Work out your monthly call volume before you decide.
What languages can I use?
The big three support the common ones out of the box: Python, JavaScript and Node.js, Java, C# and .NET, Go and more. Python and Node are the usual starting points for freshers because they start fast and keep cold starts short.
Can a serverless function run forever?
No. AWS Lambda caps a single run at 15 minutes. Long or always-on jobs belong in a container or VM. Serverless is built for short, event-driven bursts of work.
How is serverless different from containers?
A container packages an app that you still run and keep alive on a cluster. A serverless function runs only on an event and scales to zero when idle. Many teams use both: containers for the steady core, functions for the bursty edges.
Hold three ideas and you can follow almost any serverless conversation: code that runs only on a trigger, billing by the millisecond, and the cold start you pay for in latency rather than dollars. Everything else you can look up when you need it. The fastest way to make it stick is to deploy one tiny function today and watch the first call lag behind the second.
References
- AWS Lambda pricing (official)
- AWS Lambda quotas: timeout and memory limits (official)
- Azure Functions pricing (official)
- Google Cloud Run pricing (official)
About The Author
DrJha