What Is Serverless Computing? A Plain-English Guide

You've probably never thought about where your food delivery app's "order confirmed" notification actually runs. There's no single machine sitting idle waiting to send it — a tiny piece of code wakes up, fires the message, and disappears. That's serverless computing, and despite the name, it has nothing to do with there being no servers.

So what does "serverless" actually mean?

There are servers involved — plenty of them. What's missing is you having to think about them. In a traditional setup, a company rents or owns a server (a computer that runs around the clock), keeps it patched, and pays for it whether anyone's using it at 3 PM or 3 AM. With serverless computing, you write a small piece of code — called a function — and hand it to a cloud provider like AWS, Google Cloud, or Microsoft Azure. The provider runs that function only when something triggers it: a user clicking a button, a file landing in storage, a scheduled job kicking off at midnight. No trigger, no running code, no bill.

This model is often called Function-as-a-Service, or FaaS, and it's one slice of the broader cloud landscape. If you want the fuller map of how IaaS, PaaS, and SaaS fit together, Code24 has covered the full spectrum of cloud computing services separately — this piece zooms in on just the serverless slice.

What happens when you actually call one of these functions

Say an app needs to resize a photo after upload. Here's the rough sequence:

• A request hits an API gateway — think of it as a reception desk that routes incoming requests to the right function.
• The cloud provider checks if a copy of your function is already "warm" (running somewhere). If not, it has to start one from scratch — this delay is called a cold start, and it can add anywhere from a few dozen milliseconds to a couple of seconds, depending on the language and provider.
• The function runs, does its one job (resize the image), and returns a result.
• Once it's idle for a while, the provider shuts it down. You're billed only for the compute time actually used, often metered in fractions of a second.

That billing model is the real selling point. A server you rent 24/7 costs the same whether it's handling a million requests or none. A serverless function costs roughly nothing when nobody's using your app — which matters a lot more than it sounds like.

Where this actually pays off for Indian developers and startups

This is where serverless stops being a Silicon Valley talking point and becomes genuinely relevant for Indian builders. A huge share of early-stage Indian startups run lean — often a two- or three-person engineering team without a dedicated DevOps hire. Serverless removes an entire category of work: no servers to patch, no capacity planning for a festival-season traffic spike, no idle AWS bill eating into runway during the months before a product finds traction. AWS now runs regions out of Mumbai and Hyderabad, and Google Cloud and Azure both have India-based data centers too, which means a serverless backend can keep user data physically inside the country — a point that's become more than academic since the Digital Personal Data Protection (DPDP) Act started pushing companies to be deliberate about where they process and store Indian users' data.

It's not free of trade-offs, though:

• Good fit: APIs with unpredictable or spiky traffic, background jobs, webhooks, chatbots, image/video processing, anything event-driven.
• Weaker fit: Long-running processes (most providers cap function runtime at 15 minutes or less), workloads needing consistent low latency where cold starts are unacceptable, or apps where predictable high-volume traffic actually makes a fixed server cheaper.
• Worth knowing: Costs can balloon unexpectedly if a function gets called far more often than planned — unlike a fixed server bill, a serverless bill can surprise you.

Serverless doesn't mean no servers — it means no servers you have to think about.

Should you actually use it?

If you're building something today — a side project, an MVP, an internal tool at work — serverless is usually the cheapest way to get a backend running without managing infrastructure. Most providers have a free tier generous enough that a small project may never see a bill. The honest advice: don't reach for serverless because it's trendy, reach for it when your workload is genuinely bursty or your team is too small to babysit servers. For anything with steady, heavy, predictable traffic, a traditional server or container setup can end up both cheaper and more consistent. The real skill isn't picking a side — it's knowing which parts of your system actually behave like events, and which ones don't.