Serverless Computing

The spectrum lesson could not show you this part

The compute lesson placed serverless functions at the far right of the control-versus-convenience spectrum: the provider manages everything except your code, and a function starts in milliseconds. That diagram earns its place by showing where serverless sits relative to virtual machines and containers, but it cannot show what "the provider manages everything" actually means in practice, or where the edges of that convenience sit. Both matter once you are the one deciding whether a workload belongs on a serverless function at all.

No servers is the marketing name, not the mechanism

"Serverless" is the industry's name for the model, not a literal description. AWS runs your function inside an isolated micro virtual machine on its own fleet of physical servers, using a virtualization technology called Firecracker on its Nitro System; Azure and Google Cloud do the equivalent on their own hardware. What "serverless" removes is not the server, it is your job of choosing, sizing, patching, and scaling that server. Compare that to IaaS, where you pick the instance type yourself, or even PaaS, where you at least choose a runtime and a scaling policy. A serverless function hands you neither dial: you supply a function, attach a trigger, and the provider decides how many copies of it to run, where, and for how long each one lives.

The event-driven lifecycle: idle, invoke, execute, idle again

A serverless function does not sit running and waiting for work the way a virtual machine does. Picture a function that generates a thumbnail every time a customer uploads a photo to a storage bucket. Most of the day, zero copies of that function are running anywhere, and it costs nothing. The moment a photo lands in the bucket, the event triggers an invocation: the platform finds or creates an execution environment, runs your handler code against the event, and returns a result. Once the flow of uploads stops for a while, the platform reclaims that environment, and the function is back to zero.

Cold starts and warm starts

That "finds or creates" distinction has a name. If an execution environment from a recent invocation is still around, the platform reuses it, a warm start, which runs your handler almost immediately. If not, after an idle period or a burst of new traffic, the platform first has to initialize a fresh environment, load your runtime, and import your dependencies before your handler runs at all, a cold start. That initialization work is not free in time or money: current AWS Lambda billing counts the initialization phase of a cold start as billed duration, the same as the handler itself. A function invoked constantly rarely pays the cold-start tax, since environments stay warm; a function invoked in occasional bursts pays it on the first request of every burst.

The math behind "pay only for what runs"

AWS Lambda's on-demand pricing charges $0.20 per million requests plus $0.0000166667 per GB-second of execution time, with a free tier of 1 million requests and 400,000 GB-seconds every month, forever.

Take a function configured with 512 MB of memory (0.5 GB) that runs for 400 milliseconds (0.4 seconds), invoked 100,000 times a month, image thumbnailing for a small photo-sharing app, say. That workload uses 100,000 x 0.5 x 0.4 = 20,000 GB-seconds and 100,000 requests, both comfortably inside the free tier. The bill: $0.

Now scale the same function to 5 million invocations a month, a busier app, or the same app grown up. That is 5,000,000 x 0.5 x 0.4 = 1,000,000 GB-seconds, of which 600,000 are billable after the free tier, plus 4,000,000 billable requests. Duration costs about 600,000 x $0.0000166667, roughly $10.00, and requests add another 4 x $0.20 = $0.80, for a bill around $10.80 a month. Compare that to the t3.micro from the compute lesson, about $7.59 a month running around the clock whether it does any work or not. At low, spiky volume, serverless wins outright, it is free. At high, steady volume, an always-on instance can undercut it, and that is before asking whether one t3.micro could even keep up with 5 million requests without falling over.

Where a serverless function stops fitting

Two boundaries matter as much as the cost math. First, execution time: AWS Lambda functions cap a single invocation at 15 minutes; a video-encoding job that runs for 2 hours simply does not fit inside a plain function, no matter how the pricing works out. Second, state: an execution environment can be reused between invocations, but nothing guarantees it, so a function cannot rely on data staying in memory or a connection staying open between one invocation and the next. A workload that needs a long-lived database connection pool, a multi-hour batch job, or guaranteed in-memory state belongs on a container or a virtual machine instead.

Exam cues: spotting the fit in a scenario

Where this leaves you

Serverless does not remove servers, it removes your job of managing them, and it bills you only for the milliseconds your code actually runs. That trade pays off at low or spiky volume and can lose to an always-on instance at high, steady volume, which is exactly why "serverless is always cheaper" is a trap, not a rule. The next lesson leaves the question of who manages the server behind and asks a different one: how should the application itself be split into pieces, and how do those pieces run the same way everywhere. That is what containers and microservices answer.