What it is
A cold start is the delay when a serverless function runs after sitting idle. The cloud has to fetch your code, start a runtime, and then do the actual work. Warm starts skip most of that.
AWS Lambda and Azure Functions both have this pause. It is worse with big packages, certain languages, and tiny traffic. It is better if something stays warm.
Provisioned concurrency and premium plans exist to keep a function awake. You pay to avoid the wait. That is a product decision, not a surprise.
Why it matters in the meeting
Someone will say serverless has no servers. Then a customer will wait two seconds on the first click after lunch. That wait is the server, politely arriving.
JJ likes the cost story: you pay when it runs. Bart likes the latency story: the first run is the one the demo never shows.
Real world
Internal tools with five users a day feel fine. A login path or a payment webhook that sleeps all night does not. Cold starts cluster at the worst time: the first real request.
If the function talks to a database that also went to sleep, you stacked two naps. The user sees one spinner. You see two invoices that still look small.
A cold start is the cloud putting its shoes on. Fine for a report that runs at 2am. Rude for anything a person is staring at. Keep it warm, or do not put it on the front door.
What to ask
- Which customer-facing paths are Lambda or Azure Functions, and what is the p95 on a cold start?
- Do we keep those functions warm, or hope lunch traffic is patient?
- Is the package small enough, or did we ship a toolbox for a one-line job?
- If we moved the slowest function to a small always-on service, would anyone miss the purity of serverless?
You just knew a little more Jack than you did five minutes ago.
All concepts