Is serverless computing really without servers?

No. Real servers in real data centres run every serverless function. The word serverless describes your view of the job, not the hardware. You never pick a machine, size it or patch it, because the cloud company does all of that.

What is a cold start in serverless computing?

A cold start is the extra wait on the first request after a quiet spell. The platform has to build a fresh sandbox and load your code before it can answer. Later requests reuse that warm sandbox and come back faster. You can reduce cold starts by keeping your code small.

Is serverless cheaper than renting a virtual machine?

It depends on the shape of your traffic. For work that arrives in bursts, or sits quiet most of the day, serverless is usually far cheaper, because idle time is free. For code that runs hard all day, a machine rented by the month usually wins. Price both before you decide.

What is the difference between serverless and containers?

A container is a packed copy of an application that you still have to run somewhere, and it keeps running until you stop it. A serverless function is one small block of code that the cloud starts for each request and throws away after. Containers give you more control. Serverless gives you less to mind.

What is serverless computing?

You want tea for a guest, and you do not build a kitchen first. You walk to the stall on the corner, pay for one cup, and carry it home. The stall owner bought the stove, the gas and the cups, and you paid for tea.

Serverless computing works like that stall. You write a small piece of code and hand it to a cloud company, and the company runs your code when somebody asks for it. Then it bills you for the seconds the code was busy. When nobody asks, nothing runs, and the bill is zero.

The name is a poor one. THERE ARE STILL SERVERS. However, you do not own them, rent them by the month, or think about them.

What serverless really means

Serverless means you rent work. In the older way you rent a computer in a data centre. It hums along day and night, so you pay for it at three in the morning, when nobody is using your site.

In the serverless way you upload a function. A function is one small block of code that does one job. Send an email. Resize a photo. Check a password. The cloud keeps that function on a shelf. A request arrives, the cloud takes the function off the shelf, runs it, and puts it back.

This is one shape of cloud computing, and the trade name for it is functions as a service.

How it works, step by step

The chain is short, so walk through it once and the idea sticks.

Something happens. A user opens a page, a file lands in storage, or a timer strikes noon.
That event goes to the cloud platform.
The platform finds a free slot on one of its machines.
It starts a small sealed box and loads your code into it.
Your code runs and sends back an answer.
The platform keeps the box warm for a short while, in case a second request comes, and then it throws the box away.

Notice what you never did. You never picked a machine size, installed an operating system, or applied a security patch. The platform did all of that, for you and for a thousand other customers at the same time.

What you actually pay for

You pay for two things. The first is the number of times your code ran. The second is how long each run took, counted in small fractions of a second, and scaled by the memory you asked for.

Why does that matter? Because idle time is free, so a site with ten visitors a day costs close to nothing. However, the same site on a rented machine costs almost the same as a busy one.

The reverse is true as well. Code that works hard all day, every day, is usually cheaper on a machine you rent by the month. This is because serverless is priced for bursts.

What it is good at

Serverless is good at sudden crowds. Say a radio advert names your site at noon, and a thousand requests arrive in one minute. The platform starts many copies of your function, one for each request, and the crowd is served. When the rush ends, the copies vanish. You did nothing, and you paid for that minute alone.

It is also kind to small teams. This is because there is no machine to patch on a Sunday, and no disk that fills up at midnight. One person can therefore run a service used by many people.

Good jobs for serverless are short and clear. Think of a contact form, a payment callback, or a photo shrunk to make a thumbnail. Think of a nightly report mailed to a shop owner, or a small service that answers a text message.

What it is bad at

Cold starts come first. The first request after a quiet spell is slow, because the platform must build the box and load your code before it can answer. The wait is usually short, and it can still be long enough for a user to feel.

Long jobs come second. Most platforms cap how long one run may last, and the cap is counted in minutes. Therefore, a job that grinds for an hour does not fit.

Memory is the third problem. Your function forgets everything the moment it ends, so anything worth keeping must go to a database or a storage bucket. Programmers call this being stateless. Stop on that word. It means the code holds no state, so any copy of it can serve any request.

Hunting bugs is the fourth, because there is no machine to log into and poke at. You lean on logs and traces instead, and you learn to read them well.

Moving house is the last. Each cloud has its own triggers, its own names and its own limits, so code written for one platform rarely moves to another without edits. Weigh that before you build.

Where you already meet it

You meet serverless most days without seeing it. The contact form on a small shop site often runs this way. So does the message that tells you a parcel left the depot. So does the code behind a payment button, which waits for the bank to call back and then marks the order as paid.

Mobile apps use it a great deal. The app on the phone is the face, and a handful of small functions in the cloud do the work behind it. Voice helpers and chat bots often sit on the same plumbing.

How to tell it apart from a server, a virtual machine and a container

All four run your code on hardware in a data centre, and the difference is how much of the machine you must think about. A virtual machine is a whole computer made of software, which is explained in virtualization. A container is a packed parcel of one application and the few parts it needs. A serverless function is smaller than both.

Question	Own server	Virtual machine	Container	Serverless function
What do you rent?	A whole machine	A slice of a machine	A packed app	One small function
Who patches the system?	You	You	You and the host	The cloud
Does it cost money while idle?	Yes	Yes	Yes	No
How fast does it start?	Slow	Slow	Fast	Fast, once warm
What is the bill based on?	The machine	Hours it is on	Hours it is on	Run time

What to check before you choose it

Ask four plain questions about the job in front of you.

Is the traffic spiky, or quiet for long spells? Serverless fits that shape well.
Does one run finish in a few minutes? If it does not, keep a machine.
Can the job live with a slow first call?
What would the bill be at ten times the traffic you have today?

Then test it for real. Write one small function, such as the code behind a contact form, and deploy it. Send it a few hundred requests. Watch the bill for a week, and watch how long the first call of the morning takes. Those two numbers will tell you more than any guide, this one included.

Just Out Tech explains new research in plain language. This article was drafted with AI assistance and checked by a human against the original source.