Serverless, and the bill you find at the end of the month

A client called me on a Monday morning, very calm, which is always a bad sign. Their cloud bill for the previous month was ten times the ones before. The application hadn’t had ten times as many users. A function triggered by a file write was writing a file into the same folder. It had been calling itself for an entire weekend, with a great deal of diligence.

The model is appealing because it starts at zero

The principle fits in one sentence: no server to manage, you write a function, you pay for the number of calls and the compute time. For a project just starting out, it’s unbeatable. Traffic is nil, so the bill is too. A free tier often covers the first months, the infrastructure absorbs a traffic spike without anyone getting up at night, and you save the sysadmin salary a startup can’t afford.

I use this model on my own sites, this one included. I’m not going to argue that it was better with a physical server under a desk.

What pay-per-use really changes

A machine rented by the month has a known, capped cost. When it saturates, the site slows down or goes offline: that’s unpleasant, it shows up immediately, and it doesn’t cost any more. An architecture billed per execution doesn’t saturate, it absorbs. The ceiling is no longer technical, it’s financial, and you only discover it afterwards.

The expensive scenarios all share the same shape. An accidental recursion. A badly configured cache that lets every request hit the database. A crawler that finds a URL generating an image on the fly and enthusiastically walks through the parameter space. A slow external dependency that multiplies the billed time of every call by five. None of these incidents triggers an alert: everything works, the service responds, the meter keeps running.

Add the invisible part. Compute is rarely the bulk of the bill. Data egress, database queries, logs, calls between services and gateways add up in tiny lines across a bill that runs to several pages. And every service used to glue it all together is written in the dialect of a single provider, which makes leaving gradually more expensive than staying.

What I do now before deploying

I set a budget with an alert from the very first deployment, before the service is even serving anything. I put a concurrency limit on every function, even if it means degrading the service rather than the cash position. I check that no function can re-trigger itself, which seems obvious until the day it isn’t. And for a stable, predictable load, I move back to a machine rented by the month, which often costs less than a million small calls.

On the Monday in question, the provider granted a goodwill credit covering half the amount. A gesture, not a right. The bill was compliant with the contract: the service had done exactly what it was asked to do, millions of times, without ever asking why.