Serverless Done Right: When Functions Beat Containers

Quickstart

Want the fastest path to “serverless done right”? Use this as a checklist for your next service. You can apply it in 15–30 minutes.

Overview

The reason this topic is confusing is that “serverless” is marketed as a replacement for servers — but in practice it’s a different operational contract. With functions (FaaS), you typically get automatic scaling per event, pay-per-use billing, and less infrastructure to manage. With containers, you get runtime consistency, easier local reproduction, and more control.

Core concepts

Before picking a platform, it helps to understand the mechanics that actually drive the tradeoffs: execution lifecycle, state boundaries, concurrency, and failure modes.

What “serverless” means (in practice)

Cold starts: what they are and what they aren’t

A cold start is the extra time paid when the platform needs to start a new execution environment (provision runtime, load code, initialize dependencies) before it can handle an event. Cold starts are real — but they’re not always a deal-breaker. The question is: does your workload tolerate occasional slower first requests?

State, retries, and idempotency

Functions are easiest when they are stateless and idempotent. Stateless means the function can be restarted at any time without losing correctness. Idempotent means processing the same event twice produces the same final outcome. This matters because event systems often deliver messages “at least once.”

Step-by-step

This section is a practical workflow you can run on any service idea. The goal is not to pick “the best platform” — it’s to pick the platform that makes your service easier to run while meeting performance and reliability targets.

Step 1 — Describe the workload in one sentence

Use an event sentence. If you can write “When X happens, do Y, then store Z”, you’re already in function territory. If the sentence looks like “Keep a process running and accept many requests with shared in-memory state”, containers are likely better.

Step 2 — Set the constraints (the “limits doc”)

Write down non-negotiables early. This avoids building something “function-ish” that later needs to become a container because the assumptions were never stated.

Step 3 — Implement a function the “production-safe” way

The key patterns are: parse input carefully, validate early, avoid repeated heavy initialization, and shape outputs consistently. The following example shows an HTTP-style handler with JSON responses and request IDs. You can adapt it to API Gateway, Cloud Functions, or any platform that follows the “event in, response out” model.

import json
import os
import time
import uuid

# Create reusable clients outside the handler when possible (keeps warm invocations fast).
# Example: database_client = make_db_client(os.environ["DB_DSN"])

def _json(status_code: int, body: dict, request_id: str):
    return {
        "statusCode": status_code,
        "headers": {
            "content-type": "application/json",
            "x-request-id": request_id,
        },
        "body": json.dumps(body),
    }

def handler(event, context):
    request_id = (
        event.get("headers", {}).get("x-request-id")
        or str(uuid.uuid4())
    )
    start = time.time()

    try:
        # Parse JSON body (common with API gateway proxies)
        raw_body = event.get("body") or "{}"
        payload = json.loads(raw_body)

        user_id = payload.get("userId")
        action = payload.get("action")

        if not user_id or not action:
            return _json(400, {"error": "userId and action are required"}, request_id)

        # Idempotency key pattern: caller provides a unique key per logical action.
        idem_key = payload.get("idempotencyKey") or f"{user_id}:{action}"
        # TODO in real systems: store idem_key in a DB with a write-once constraint.
        # If seen before, return the previously computed result.

        # Do work (keep it short; push heavy work to async queue)
        result = {"ok": True, "userId": user_id, "action": action}

        duration_ms = int((time.time() - start) * 1000)
        return _json(200, {"result": result, "durationMs": duration_ms}, request_id)

    except json.JSONDecodeError:
        return _json(400, {"error": "invalid JSON"}, request_id)
    except Exception as e:
        # Avoid leaking secrets; return a safe error shape.
        return _json(500, {"error": "internal_error", "message": str(e)}, request_id)

Step 4 — Add concurrency control and backpressure

The “functions beat containers” story only stays true if you protect downstream systems. Your database and third-party APIs typically cannot scale as fast as your function platform. Use queues, rate limits, and concurrency caps to keep the system stable.

Step 5 — Choose deployment primitives (don’t over-engineer)

Many teams mix functions and containers: functions for event handling and glue, containers for stable APIs and long-running services. Infrastructure-as-code makes this mix manageable. The following Terraform example illustrates a simple decision: create a function for webhook handling, and a container service for a steady API (shown as a placeholder you can map to your platform).

# Minimal example: one serverless function + one container service placeholder.
# Adapt resources to your cloud/provider.

variable "project" { type = string }
variable "env"     { type = string }

# Serverless function (webhook handler)
resource "aws_lambda_function" "webhook" {
  function_name = "${var.project}-${var.env}-webhook"
  role          = aws_iam_role.lambda_exec.arn

  handler = "app.handler"
  runtime = "python3.12"

  # Package produced by CI (zip uploaded to S3 or local file). Placeholder values:
  filename         = "dist/webhook.zip"
  source_code_hash = filebase64sha256("dist/webhook.zip")

  timeout     = 10
  memory_size = 256

  environment {
    variables = {
      LOG_LEVEL = "INFO"
    }
  }
}

resource "aws_iam_role" "lambda_exec" {
  name = "${var.project}-${var.env}-lambda-exec"
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Effect = "Allow",
      Principal = { Service = "lambda.amazonaws.com" },
      Action = "sts:AssumeRole"
    }]
  })
}

# Container service placeholder: use ECS/Fargate, Cloud Run, or similar.
# The point: keep steady APIs in containers when you need consistent warm capacity.
output "container_service_hint" {
  value = "Deploy steady API in a managed container service; keep webhook/event handlers as functions."
}

Step 6 — Wire CI/CD with safe defaults

CI/CD operational simplicity is one of the real wins of serverless. But don’t trade it for mystery: keep deployments repeatable, use environment-specific configs, and avoid “click-ops.” Here’s a compact GitHub Actions workflow that builds a function package and applies Terraform using OIDC (no long-lived cloud keys).

name: deploy

on:
  push:
    branches: [ "main" ]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Build function package
        run: |
          set -euo pipefail
          rm -rf dist && mkdir -p dist
          # Example packaging (adjust for your build system):
          zip -r dist/webhook.zip app.py

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/ci-deploy-role
          aws-region: eu-central-1

      - name: Terraform apply
        run: |
          set -euo pipefail
          terraform init
          terraform apply -auto-approve \
            -var="project=unilab" -var="env=prod"

Step 7 — Validate with a “day-2” checklist

The most important question is what happens after launch. Run this checklist on your serverless service:

Common mistakes

Most “serverless horror stories” are avoidable. They usually come from forcing the wrong execution model onto the workload or skipping the boring reliability patterns (limits, retries, idempotency, and observability).

FAQ

When do functions beat containers?

Functions usually beat containers when the workload is event-driven, bursty, and stateless: webhooks, scheduled jobs, queues, stream processing, and “glue” between managed services. You get automatic scaling per event and pay-per-use economics without running an always-on fleet.

When are containers the better choice?

Containers are typically better for long-running processes, stable low-latency APIs with strict P99 budgets, services that maintain long-lived connections (WebSockets/streams), and workloads that need custom runtime control (networking, binaries, sidecars, or specialized tuning).

Are cold starts a deal-breaker for serverless?

Not automatically. Cold starts matter most for interactive, latency-critical endpoints. For async pipelines and event handlers, they’re usually fine. Mitigate by shrinking dependencies, reusing clients, and using warm pools/provisioned concurrency only for paths that truly need it.

How do you make serverless reliable with retries?

Treat retries as a fact of life and build idempotency into your side effects. Use an idempotency key, store write-once records, and ensure duplicate events don’t create duplicate charges/emails/rows. Combine this with DLQs and alerting on backlog growth.

What’s the biggest operational benefit of serverless done right?

You reduce day-to-day operations for bursty workloads: no capacity planning, no fleet management for idle time, and simpler scaling. The tradeoff is that you must be disciplined about limits, observability, and downstream protection to avoid surprise throttles and cascading failures.

Is “serverless” cheaper than containers?

It depends on utilization. Functions can be cheaper for spiky/low-duty-cycle workloads because you pay mostly for usage. Containers can be more cost-effective for steady high-throughput services where always-on capacity is fully utilized. Cost comparisons should include operational overhead and reliability work, not just compute pricing.

Cheatsheet

A scan-fast guide for picking the right runtime and avoiding the common serverless pitfalls.

Wrap-up

Serverless done right isn’t about banning containers — it’s about matching the execution model to the workload. Use functions for event-driven, bursty automation where you want “scale to zero” and simple operations. Use containers for long-running services, stable low-latency APIs, and workloads that need tight runtime control.

Related posts

• Terraform Mistakes: State, Modules, and the ‘One Big Plan’ Trap
• Cloud Cost Optimization: 15 Leaks You Can Fix This Month
• Cloud Networking Basics: VPCs, Subnets, NAT, and Security Groups
• Docker for Developers: Images, Layers, and Caching Explained
• Kubernetes Without Tears: Pods, Services, Ingress in One Story
• CI/CD That Stays Green: Pipeline Patterns That Scale