Lambda vs Containers

WHAT IS BEING DECIDED How application code runs: as functions invoked per request, or as containers running continuously behind a load balancer. The decision turns on traffic shape far more than on preference — the same code can be cheap in one model and expensive in the other purely because of how requests arrive. HOW TO WEIGH IT Weight cost-at-your-traffic-shape heavily and calculate it rather than estimating: spiky or low-volume traffic is dramatically cheaper as functions, while steady high-volume traffic is dramatically cheaper as containers. The crossover is real and findable with a spreadsheet. Weight cold-start tolerance heavily for user-facing synchronous paths. Weight portability by whether you might move clouds, since a function is a deeper coupling to the platform than a container is. WHEN EACH WINS Lambda wins for event-driven and intermittent work: scheduled jobs, queue consumers, webhook handlers, and anything whose traffic is bursty or occasional. Paying nothing while idle is a genuine advantage, and there is no fleet to patch. Containers win for sustained traffic, long-running or stateful-ish processing, workloads needing large memory or specialised runtimes, and anywhere consistent low latency matters more than idle cost. They also win when you want one runtime model across everything rather than two. HOW TO DECIDE Model the monthly cost at your actual request volume and duration profile, then check whether cold starts are acceptable on your latency-sensitive paths. Those two answers usually decide it. A mixed estate is legitimate — functions for events, containers for the request path — provided you accept operating two deployment models. See /noops for an honest account of what managed runtimes remove, and /finops for the cost modelling.