Choosing between functions and serverless containers: when (and when not) to use serverless for your backend

Serverless is no longer a single thing. Today “serverless” can mean tiny edge functions that start in milliseconds, cloud functions that auto-scale to zero, or container-based serverless platforms that accept any container image and run it with autoscaling and longer timeouts. Picking the right flavor for your backend matters: the wrong choice can cost you performance, predictability, or money. This article walks through practical rules-of-thumb—when to choose functions (FaaS), when to prefer serverless containers, and when to avoid serverless entirely.

Quick primer: the important differences

• Functions (AWS Lambda, Cloudflare Workers, Azure Functions) are optimized for short, event-driven work: they scale quickly and you pay per invocation/time used. Providers give features to reduce cold starts (provisioned concurrency, SnapStart), but runtime, memory and execution-time limits still apply. (docs.aws.amazon.com)
• Serverless containers (Google Cloud Run, AWS Fargate) accept arbitrary container images, let you control concurrency per instance, and usually allow much longer request timeouts. That makes them closer to managed containers with zero-to-many scaling. (docs.cloud.google.com)
• Edge workers (Cloudflare Workers, Fastly Compute@Edge) run near users for ultra-low latency and are great for request-side logic, though they have their own execution and resource limits. (developers.cloudflare.com)

When to use functions (FaaS)

• Event-driven glue and background jobs: small tasks triggered by events (queue messages, webhooks, cron jobs) are a perfect fit—cold starts and short-lived invocations aren’t usually a problem. (docs.aws.amazon.com)
• Spiky, unpredictable traffic: pay-per-use pricing removes the need to provision capacity for peaks you rarely see. Empirical studies show serverless often wins for highly variable workloads. (arxiv.org)
• Lightweight APIs and microservices where each endpoint executes brief logic and talks to managed services (databases, object stores).
• Edge personalization, A/B testing, or request rewriting: run logic close to users to cut latency using worker platforms. (developers.cloudflare.com)

Practical advantage: minimal operational surface—no container build/repo to manage, and instant scaling to zero avoids idle compute charges. But beware runtime constraints and cold starts for heavy runtimes; providers offer mitigations like provisioned concurrency and snapshot-based warm starts for Java. (docs.aws.amazon.com)

When to prefer serverless containers

• Long-running requests or complex init: if requests can legitimately take minutes, the longer timeouts of container-based serverless matter (Cloud Run supports up to 60 minutes per request). (docs.cloud.google.com)
• Stateful connection lifetimes and concurrency control: container instances can accept multiple concurrent requests and keep in-memory caches or pooled DB connections, which reduces per-request overhead compared with one-process-per-invocation function models. (docs.cloud.google.com)
• Native dependencies and custom runtimes: heavy binaries, custom system libraries, or GPU drivers are easier to package in a container image than in restrictive function runtimes.
• Predictable, sustained traffic: when you have steady mid-to-high load, a container instance handling many concurrent requests often costs less than many function invocations.

Serverless containers are a practical middle ground: you still get autoscaling and lower ops, but with the flexibility of regular containers.

When not to use serverless (either flavor)

• High-performance, CPU-bound workloads at scale: things like batch number-crunching, large-scale media transcoding, or sustained ML training are usually cheaper and more predictable on reserved instances, VMs, or dedicated clusters. Empirical work shows cost and performance for serverless can worsen for consistently high utilization. (arxiv.org)
• Very low-latency strict SLAs: while edge workers can cut latency, functions that experience cold starts (or unpredictable scaling delays) may not meet tight p99/p999 targets unless you pay for provisioned capacity. (docs.aws.amazon.com)
• Heavy in-memory state and long-lived sockets: serverless tends to favor ephemeral compute; if your app relies on long-lived TCP connections or very large in-memory datasets, managed VMs or containers are more appropriate.

A simple decision checklist

• Is the work short (sub-seconds to a few seconds) and event-driven? → Function.
• Does the request need long startup or long runtime (> few minutes)? → Serverless container or VM. (docs.cloud.google.com)
• Is traffic spiky/unpredictable? → Functions often reduce cost and ops. (arxiv.org)
• Do you need low per-request latency at the edge? → Edge workers. (developers.cloudflare.com)
• Will you have sustained, CPU-heavy throughput? → Prefer reserved instances, dedicated containers, or specialized compute.

Mitigations and practical tips

• Measure first: instrument representative traces to understand init time, cold starts, and request durations.
• Mix and match: many teams use functions for glue and events, containers for APIs that need custom runtimes, and edge workers for latency-sensitive request path work.
• Use provider features intentionally: provisioned concurrency, SnapStart, or keeping a small “warm” fleet can reduce latency but increases cost—treat these as tradeoffs and quantify them. (docs.aws.amazon.com)

Conclusion Serverless is powerful, but it’s not a one-size-fits-all replacement for containers or VMs. Match the model to workload characteristics—latency sensitivity, runtime length, concurrency needs, and traffic shape. When you choose the right serverless flavor (or mix of flavors), you get much of the operational simplicity and scaling magic without surprising performance or cost.

Sources (selected)

• AWS Lambda limits and quotas. (docs.aws.amazon.com)
• AWS documentation on Provisioned Concurrency. (docs.aws.amazon.com)
• AWS Compute Blog: Lambda SnapStart (cold-start mitigation). (aws.amazon.com)
• Google Cloud Run docs (timeouts, concurrency). (docs.cloud.google.com)
• Cloudflare Workers overview and limits (edge functions). (developers.cloudflare.com)
• Empirical study on serverless cost dynamics and workload suitability. (arxiv.org)