Serverless and Functions

What if you didn't have to think about servers at all — just write a piece of code, and let the cloud run it whenever it's needed? That's the idea behind serverless computing.

With a virtual machine you manage a whole computer. With containers you manage packaged environments. With serverless, you hand the cloud a small piece of code — a function — and the cloud handles everything else: where it runs, on how many machines, and how to scale it. You write the logic; the provider takes care of the rest.

A good analogy is a motion-sensor light. It switches on the moment someone walks in and switches off when the room is empty. You never tend it, size it, or pay for the hours it's dark. A serverless function works the same way: it turns on when triggered, does its job, and stops. Nothing runs while idle; nothing bills while idle.

"Serverless" Is a Slightly Misleading Name

There are still servers. There have to be — code runs on hardware. What "serverless" really means is that you never see or manage those servers. The provider spins one up when your function is triggered, runs the function, and takes the server away when done. From your perspective, no server exists: you just have code that runs on demand.

This is the farthest point on the "let the provider manage it" spectrum. With a VM, you manage the operating system. With containers, you manage the packaged environment. With serverless, you manage only the code itself — nothing below that is your concern. The same principle — no servers to manage, pay only for what runs — also applies to serverless databases and other fully managed services, not just functions.

Functions: Small Pieces of Code, Run on Events

The unit of serverless computing is a function — a small, self-contained piece of code with one specific job. A function runs in response to an event: a file is uploaded, a message arrives, a web request comes in, a timer fires. The function runs, does its job, and exits.

Functions are designed to be short-lived — typically finishing in seconds or minutes. They aren't meant for long, continuous workloads. They're ideal for tasks like: resize this image when it's uploaded, send this notification when an order is placed, validate this form when it's submitted.

Pay Only When It Runs

A virtual machine that sits idle still costs money — the provider is holding resources in reserve for you. A serverless function costs nothing while it isn't running. You're billed only for the actual milliseconds of execution, multiplied by how much memory the function used.

For workloads that run only occasionally — or that spike unpredictably and then go quiet — this billing model can be dramatically cheaper than keeping a VM running around the clock. A function that handles one file upload an hour costs a fraction of a cent per day.

The Trade-Off

Serverless isn't the right shape for everything. Functions have limits on how long they can run — up to 10–15 minutes on most platforms, and up to 60 minutes for HTTP-triggered functions on Google Cloud (event-driven functions are shorter) — and a function that hasn't run in a while may take an extra moment to start — a "cold start" — before responding. Some workloads need constant, long-running processing; a serverless function isn't built for that.

And giving up the server also means giving up the control. You can't tune the operating system, install unusual software, or keep state between invocations without external help. For many jobs that trade-off is worth it; for others it isn't. Recognizing which is which is a recurring cloud architecture decision.

Event occursa trigger fires

→

Function startsprovider runs the code

→

Task completesresult returned

→

Function stopsnothing idles or bills