Serverless Functions: What They're Actually Good For

Serverless functions get pitched as a way to stop thinking about infrastructure entirely, which oversells them slightly — they're an excellent fit for a specific category of workload, and a genuinely awkward one for others, regardless of how appealing "no servers to manage" sounds in a sales pitch.

Where serverless genuinely shines

• Infrequent, bursty workloads — a task that runs occasionally and needs to scale instantly when it does, without paying for idle capacity between runs.
• Simple, stateless operations — image resizing, sending a notification, processing a webhook — that don't need to maintain any state between invocations.
• Rapid prototyping, where getting something running without provisioning and managing a server has real speed benefits early in a project's life.

Where it becomes an awkward fit

Long-running processes hit execution time limits most serverless platforms impose. High-frequency, sustained traffic can end up costing more than a traditional server once volume passes a certain threshold. And cold starts — the delay when a function hasn't run recently — can introduce latency that matters for user-facing, latency-sensitive requests.

How this fits into a broader hosting decision

We often end up with a hybrid: a traditional server or container handling the core application, with serverless functions picking up specific, well-suited background tasks — the same nuanced, workload-specific thinking behind any hosting decision generally.

Serverless doesn't mean no infrastructure decisions. It means different infrastructure decisions, and they still need to match the actual shape of your workload.

This is also a natural fit inside a small team's CI/CD pipeline for specific automated tasks, without needing to provision and maintain a server just to run something occasionally.