Serverless

Code runs on demand on platform-managed compute, scales to zero, and charges per execution. The platform handles capacity; the customer handles application logic and configuration.

“Serverless” is a misnomer; there are servers, but the customer doesn’t manage them. The pricing model and the operational profile are what distinguish the category.

        flowchart LR
    subgraph T[Triggers]
        http[HTTP Request]
        sched[Schedule]
        queue[Queue Message]
        obj[Object Storage Event]
    end

    subgraph F[Functions]
        f1[Function 1]
        f2[Function 2]
        f3[Function 3]
        f4[Function 4]
    end

    subgraph S[Stores]
        db[(Managed DB)]
        bucket[(Object Storage)]
        cache[(Managed Cache)]
    end

    other[Other Service]

    http  --> f1
    sched --> f2
    queue --> f3
    obj   --> f4

    f1 --> db
    f2 --> bucket
    f3 --> cache
    f4 --> other
    

Forms

The four forms “serverless” can take in 2026. FaaS for single- function event handlers; container-based serverless when you want a longer-running unit; edge functions for latency-near- user; BaaS when the boundary blurs into managed-database land.

• Functions-as-a-Service (FaaS), AWS Lambda, Google Cloud Functions, Azure Functions. Single function, single trigger.

• Container-based serverless, AWS Fargate, Cloud Run, Container Apps. Bring a container; the platform schedules and scales it.

• Edge functions, Cloudflare Workers, Vercel Edge Functions, Deno Deploy. Tiny runtime, distributed near users.

• Backend-as-a-Service (BaaS), managed primitives like Firebase Firestore, Supabase, Hasura. The boundary blurs.

Strengths

What serverless does that always-on infrastructure can’t. The “no idle cost” story is the headline; trivial scaling and zero-fleet-management are the operational wins; tight cloud integration is what makes the model genuinely productive for event-driven workloads.

• No idle cost, pay only for what you use.

• Trivial scaling, the platform handles spikes.

• No fleet management, no patching, no autoscaling configuration, no capacity planning.

• Tight cloud integration, triggers from queues, storage, schedule, HTTP, IoT.

• Fast first deploy, “hello world” to production in minutes.

Costs

The hidden bill that catches teams new to serverless. Cold starts, vendor lock-in, observability gaps, runtime constraints, and cost surprises under sustained load are all real, and most of them only show up after the first month of production use.

• Cold starts, the first request after idle pays a startup tax. Worse on high-level languages (.NET, Java, Python) than on Go / Rust / JavaScript.

• Vendor lock-in, function signatures, triggers, IAM, observability all platform-specific.

• Observability gaps, short-lived processes don’t fit traditional agents; the platform supplies most of the data.

• Runtime constraints, max execution time, memory, request size, filesystem limits.

• Cost surprises, under sustained load, FaaS can be more expensive than a always-on container.

• Local dev complexity, emulators are imperfect; round-tripping to the cloud during development is common.

Sweet Spots

Serverless wins when the workload matches the pricing model (spiky, event-driven, glue code, or scheduled). The list below covers the workload profiles where the no-idle-cost and trivial-scaling story actually pays back the operational constraints.

• Event-driven, “when X happens, do Y”.

• Spiky, traffic that idles and surges.

• Glue between cloud services, thin code with managed primitives doing the heavy lifting.

• Scheduled jobs, cron without a host.

• Low traffic, the no-idle-cost story dominates.

• Edge-near, when latency to users matters more than batch throughput.

Anti-patterns

The workload types that fight serverless rather than fit it. Each one ends up paying serverless prices for a problem serverless wasn’t built to solve (long-running batch, heavy runtimes, stateful workloads, synchronous chains, tight CPU loops).

• Long-running batch processing in FaaS with hard time limits.

• Heavy-startup runtimes with high cold-start sensitivity.

• State-heavy workloads, stateless is the assumption; state has to go somewhere else.

• Synchronous chains of functions, timeouts compound; cost compounds.

• Tight CPU loops, billed by time × resources.

State

Functions are stateless by design. Designing for serverless mostly means designing the data layer to scale alongside, since nothing about state ships with the function. Common stores.

• Managed databases (DynamoDB, Firestore, Aurora Serverless).

• Object storage (S3, GCS, Blob).

• Caches (ElastiCache Serverless, Upstash Redis, Cloudflare KV / R2).

• Queues / streams (SQS, EventBridge, Kafka, Pub/Sub).

Designing for serverless usually means designing the data layer to scale alongside.

Cold Starts

The startup tax serverless pays when no warm instance is sitting ready. The mitigations below trade some of the no-idle-cost benefit for predictable latency, or shrink the startup itself through smaller packages and faster runtimes.

• Provisioned concurrency, pre-warmed instances; partial scale-to-zero loss but predictable latency.

• Smaller deployment packages, fewer dependencies, smaller binaries.

• Faster runtimes, Go, Rust, JavaScript, Bun’s bundled runtime.

• Edge runtimes, typically sub-10 ms cold start by design.

• Init outside handler, expensive setup at module load runs once per warm instance.

Local Development

The friction point most serverless teams hit. Local emulators diverge from the real cloud in subtle ways; the standard answer in 2026 is to run integration tests against ephemeral cloud environments rather than perfect emulators.

• AWS SAM, Serverless Framework, SST.

• Cloudflare Wrangler, Vercel CLI, Netlify CLI.

• LocalStack for AWS service mocking.

Local environments diverge from production; integration tests against ephemeral cloud environments are usually more reliable than emulators.

Cost

A useful mental model for “is this cheaper than a container?” The crossover point depends on duty cycle: serverless wins for spiky / low-utilization workloads; always-on containers win once utilization sustains above 30-50%. Track cost per request, not just total; surprises live in the math.

• FaaS, per-request charge + (memory × duration). Sub-second responses are cheap; long-running ones aren’t.

• Container serverless, per-second-while-running plus traffic. Cheaper for steady load.

• Always-on container wins when utilization > ~30-50%; serverless wins below.

Track cost per request, not just total. Surprises live in the math.

When to Reach for Serverless

The use cases where serverless is the obviously-correct choice in 2026. Most are about variability (bursty traffic, scheduled work, event-driven triggers, edge-near placement) where the no-idle-cost story dominates.

• APIs with bursty traffic and idle periods.

• Cron, scheduled tasks, webhooks.

• IoT / streaming triggers from cloud services.

• Image / video processing with per-event triggers.

• Edge personalization / A-B routing close to users.

• Internal tools that don’t justify a full deployment.

When to Skip

The cases where serverless costs more or works worse than the alternative. Sustained traffic, latency-sensitive paths, heavy-startup runtimes, hard runtime limits, and integration- test workflows that need local fidelity all point away from serverless.

• Sustained high-traffic workloads (always-on is cheaper).

• Real-time / very-low-latency systems where cold starts hurt.

• Heavy-startup runtimes in latency-sensitive paths.

• Tight integration tests requiring local-only environments.

• Anything with hard egress / runtime limits the platform won’t lift.