Picking the Right Serverless Use Case: when (and when not) to use serverless for your backend

Serverless computing is no longer a cutting‑edge experiment — it’s a mature set of options that includes classic FaaS (AWS Lambda, Google Cloud Functions, Azure Functions), serverless containers (Cloud Run, Fargate), and edge runtimes (Cloudflare Workers, Vercel Edge Functions). But “serverless” is a spectrum, not a single silver bullet. This article walks through practical, recent trade‑offs so you can choose serverless where it makes sense — and avoid it where it doesn’t.

Why revisit this now

• Edge runtimes and stateful serverless primitives (Durable Objects, Durable/Step/Orchestrator workflows) have changed what “serverless” can do at low latency and globally. Cloud providers have also added features (provisioned concurrency, serverless containers) to address cold starts and long‑running tasks. These changes matter when deciding whether serverless is a fit. (developers.cloudflare.com)

Core decision points (quick summary)

• Use serverless when: workloads are event‑driven, spiky, short‑lived, or you want to reduce ops overhead and pay only for use. (cloudflare.com)
• Avoid (or augment) serverless when: you have sustained, high, or predictable throughput; need long‑running CPU/GPU jobs; require complex transactional state kept in memory; or you need guaranteed sub‑millisecond cold‑start latency without provisioned capacity. (spendark.com)

When serverless shines

• Spiky or unpredictable traffic. If traffic bursts (marketing campaigns, scheduled releases, seasonal traffic), serverless auto‑scales without pre‑provisioning capacity and you pay only while code runs. This is the classic serverless economic win. (cloudflare.com)
• Event‑driven pipelines and glue code. Functions are ideal for message processing, webhook handlers, ETL steps, cron jobs, and small transformations in a distributed pipeline. Built‑in integrations (pub/sub, storage triggers, managed queues) simplify wiring. (aws.amazon.com)
• Short request/response APIs where per‑request duration is low. For low‑to‑medium traffic APIs with short processing time, the per‑invocation billing model is usually more cost‑efficient than always‑on VMs or containers. (kth.diva-portal.org)
• Edge logic and global low‑latency processing. Edge runtimes (V8 isolates used by Cloudflare Workers and similar products) deliver millisecond cold starts and let you run logic closer to users for faster responses and lower egress latency. That matters for localized routing, CDN logic, and A/B tests. (developers.cloudflare.com)

When serverless is a poor fit

• High, steady throughput with sustained compute. When your functions run constantly (e.g., steady 24/7 traffic) per‑invocation billing often becomes more expensive than an always‑on container or VM. There’s a break‑even point; beyond it, dedicated instances or containers win on cost. (spendark.com)
• Long‑running or heavy compute / GPU tasks. Functions usually have execution time limits and cost models that penalize long duration. For extended CPU, memory, or GPU jobs, prefer batch, container, or VM solutions. (docs.cloud.google.com)
• Strict low‑latency SLAs that can’t accept variability. Cold starts — the delay while a new function instance initializes — still exist for many FaaS platforms and can add tens to hundreds of milliseconds depending on language and runtime. If you can’t tolerate that variability, either use provisioned concurrency, an edge runtime with isolates, or move to containers/VMs. (aws.amazon.com)
• Complex in‑memory, transactional state. Traditional FaaS is stateless by design; keeping consistent in‑memory state across requests is hard. Use managed state/orchestration primitives (Durable Functions, Step Functions, Durable Objects) or a container/VM with an attached database when you need complex transactional state or long‑lived in‑memory sessions. (learn.microsoft.com)

Cold starts: how much do they matter today?

• The short version: cold starts can still be noticeable for some languages and heavy frameworks, but providers offer mitigations. AWS Provisioned Concurrency lets you pre‑warm a configurable number of Lambdas to remove cold‑start latency for those instances; edge runtimes using isolates often have near‑zero cold start for typical code. However, provisioned concurrency comes with predictable cost because you pay for the reserved instances. (aws.amazon.com)

Cost tradeoffs: beyond headline pricing

• Serverless pricing is typically request + duration (GB‑seconds). That makes it excellent for spiky, low‑utilization systems, but if you have sustained usage the math flips. Add the cost of API gateway, proxies, and any orchestration or logging, and the per‑request bill can rise faster than expected. Many recent analyses show a clear cross‑over point: the higher your steady traffic and per‑request duration, the more likely a container or VM is cheaper. Use realistic traffic profiles when comparing. (kth.diva-portal.org)

Stateful serverless: the new possibilities (and limits)

• Providers have introduced stateful serverless patterns. Azure Durable Functions and AWS Step Functions give you managed orchestration for multi‑step workflows and long‑running processes without managing servers. Cloudflare Durable Objects let you hold per‑entity state and even support WebSockets and hibernation to reduce costs for mostly‑idle connections. These features expand serverless use cases considerably — but they also introduce new operational and cost considerations, and they don’t magically replace a database or a properly designed transactional system. (learn.microsoft.com)

A short decision checklist

• Use serverless if:
  • Traffic is bursty or unpredictable. (cloudflare.com)
  • Workloads are short‑lived (milliseconds to a few seconds). (kth.diva-portal.org)
  • You want minimal infra ops and fast time‑to‑market. (cloudflare.com)
  • You need global, low‑latency edge logic (A/B tests, caching rules, small transformations). (developers.cloudflare.com)
• Consider alternatives if:
  • Traffic is predictable, sustained, and high (run cost model math). (spendark.com)
  • You need long‑running compute/GPU. (docs.cloud.google.com)
  • You need complex, transactional in‑memory state across many requests and users (unless you adopt Durable Objects / orchestrator patterns). (developers.cloudflare.com)

Practical patterns and hybrid approaches

• Serverless + containers: Use functions for event glue and bursty paths, run core steady services in containers (Cloud Run, ECS/Fargate, Kubernetes) to control costs and connection behavior. Cloud Run gives serverless-style scaling for containerized workloads and supports concurrency per instance for efficiency. (docs.cloud.google.com)
• Warm pools and provisioned concurrency: If you pick FaaS for latency‑sensitive endpoints, apply provisioned concurrency (or warmers) for critical paths and leave non‑critical paths to on‑demand functions to control cost. Remember this shifts some cost to “always provisioned” charges. (aws.amazon.com)
• Move state to managed services where appropriate: Persist complex state in a DB or a managed state tier and use functions as stateless processors or orchestrators. If you truly need per‑entity in‑memory state at the edge, evaluate Durable Objects or equivalent services but watch for new billing patterns. (docs.aws.amazon.com)

Tiny example: edge function handler (Cloudflare Worker)

• This minimal example shows how compact an edge serverless handler can be:
  • JavaScript (Cloudflare Worker) fetch handler:

    export default {
    async fetch(request) {
      const url = new URL(request.url);
      if (url.pathname === '/ping') return new Response('pong', {status: 200});
      return new Response('Hello from the edge', {status: 200});
    }
    };
    

    Edge runtimes boot very fast (V8 isolates) and run close to users, which reduces latency for global audiences. (developers.cloudflare.com)

Wrapping up — a pragmatic mindset

• Serverless is a powerful set of tools, not a panacea. Treat it like a new family of deployment knobs: a great fit for spiky, event‑driven, and edge use cases; less ideal for steady, heavy, or highly stateful workloads unless you adopt orchestrators or special state services. Evaluate with real traffic shapes, include gateway/orchestration costs in the math, and consider hybrid architectures (functions for bursts and glue, containers for steady services) to get the best of both worlds. (spendark.com)

Further reading (recommended vendor docs and analyses cited above)

• Cloudflare Workers / Durable Objects documentation and technical posts on edge isolates and WebSockets. (developers.cloudflare.com)
• AWS Lambda docs on Provisioned Concurrency and pricing pages. (docs.aws.amazon.com)
• Google Cloud Run vs Cloud Functions guidance (serverless containers). (cloud.google.com)
• Microsoft Durable Functions overview for stateful serverless workflows. (learn.microsoft.com)
• Recent cost and trade‑off analyses comparing serverless and container pricing models. (spendark.com)

Choose the runtime and pricing model that matches your traffic shape, latency targets, and state needs — and you’ll get serverless to work for you instead of against you.