28 September 202610 min read

Swiss Cases: Choose Serverless or Containers by RPS and Runtime

A 1980s taxi meter with an amber display next to a toy lorry carrying three small shipping containers.

Prefer serverless for short-lived, event-driven workloads and containers for long-running, stateful, or high-resource services. The main reasons are how each model scales, how you get billed, and how much operational control you keep: serverless trades control for convenience, while containers trade convenience for predictable performance and portability.

TL;DR:

Containers are preferred for workloads with steady, predictable traffic due to their cost-effectiveness and predictable performance, while serverless suits bursty, event-driven traffic.

Kubernetes autoscaling reacts slowly to external metrics, whereas serverless functions scale nearly instantly, impacting latency-sensitive applications.

Container-based workloads support stateful connections and long-lived sessions more easily than serverless functions, which are designed to be stateless.

Cost differences are significant: containers charge for reserved capacity regardless of usage, while serverless bills per request and execution time, favoring intermittent workloads.

Team expertise, workload predictability, and data residency requirements are critical factors in selecting the right architecture, with hybrid patterns common in production systems.

What are containers?

A container packages an application with its dependencies into a single image, built to the OCI (Open Container Initiative) format so it runs the same way on a laptop, a test server, or a production cluster. Underneath, containers rely on Linux namespaces for isolation and cgroups to cap CPU and memory, which is why several containers can share one host without stepping on each other.

Running one container is simple. Running hundreds in production is where Kubernetes comes in. Kubernetes schedules containers onto nodes, restarts ones that fail, and uses the Horizontal Pod Autoscaler to add or remove replicas based on CPU, memory, or custom metrics, checked on a recurring sync interval rather than instantly. It also handles service discovery so containers can find each other by name, and rolling updates so you can ship a new version without downtime.

The operational lifecycle around containers looks like this:

Build a container image and push it to a registry as part of your CI/CD pipeline.
Deploy the image to a cluster where Kubernetes schedules it onto available nodes.
Monitor and patch the underlying nodes, since you are responsible for the operating system and runtime.
Scale replicas manually or automatically as load changes.

That last point is the tradeoff: you get full control over the runtime environment, but you also own the maintenance that comes with it, from node upgrades to security patching.

What is serverless?

Serverless, more precisely function as a service (FaaS), lets you deploy a single function that runs in response to an event: an HTTP request, a queue message, a file upload. There is no server to provision or patch. The platform starts an execution environment, runs your code, and shuts it down when the work is done.

Billing follows the same logic. Instead of paying for a running server, you pay for requests and execution time, usually metered down to the millisecond, along with the memory you allocate. AWS Lambda is the most widely used implementation of this model, and its constraints shape how you design around it.

Key mechanics to know before you commit to serverless:

Functions have a maximum runtime and a memory ceiling, so long-running or memory-heavy jobs need a different architecture.
Reserved concurrency guarantees a function a slice of capacity, while provisioned concurrency pre-initializes environments to cut cold starts, at an added cost applied per version or alias.
Serverless functions typically call out to managed services like an API gateway or a managed database rather than hosting that logic themselves.
Invocation behavior differs between synchronous calls, which return a response directly, and asynchronous ones, which can retry or route failures to a dead-letter queue.

This model shines when traffic is burst or unpredictable, since you are not paying for idle capacity between events.

Key differences that actually drive the decision

The two models diverge sharply once you look past the marketing pitch, and the differences map to workload signals you can measure before you build anything.

Autoscaling behavior. Kubernetes HPA reacts to metrics on a sync interval and scales replicas within limits you set, while tools like KEDA extend that model to react to external metrics such as queue depth, closing much of the gap with function-style elasticity. Serverless platforms scale per invocation almost instantly, which suits spiky traffic but removes fine-grained control over how many instances run at once.
Cost model and surprise costs. Containers cost you for the capacity you reserve whether or not it is used, while serverless bills per request and duration, which is cheaper for intermittent workloads and more expensive for constant, high-volume ones. On AWS Lambda, memory allocation scales CPU proportionally, so bumping memory to speed up a slow function can quietly raise your bill if the workload was never CPU-bound to begin with.
Latency and cold starts. A container that is already running responds immediately, but a function that has been idle needs to initialize an environment first, adding latency. Provisioned concurrency on Lambda and pre-warmed container pools both address this, at the cost of paying for idle capacity again.
Statefulness. Containers can hold in-memory session state or long-lived connections across requests; serverless functions are designed to be stateless and typically push session data to an external store, which is why stateful workloads default to containers.
Portability and lock-in. A container image runs on any OCI-compatible runtime, and Kubernetes itself is a portable abstraction across clouds. Serverless functions are built against a specific provider’s APIs, event formats, and limits, which makes migrating between providers a rewrite rather than a redeployment.
Tooling and observability. Container platforms have mature tracing and debugging tooling built around long-lived processes, while serverless debugging depends more heavily on logs and platform-specific tracing, since you cannot attach a debugger to an environment that no longer exists once the invocation ends.

Pro Tip: Before choosing a scaling model, benchmark your function or container under realistic load and track mean runtime, peak concurrency, and memory usage. Those three numbers tell you more about fit than any architecture diagram.

Where the two models overlap and how teams combine them

Containers and serverless share the same cloud-native foundations: microservices, immutable deployments, and CI/CD pipelines that ship small, independent units of code. The split is less absolute in practice than in theory.

A common hybrid pattern runs core services, such as an API or a stateful backend, in containers on Kubernetes, while event handlers, webhooks, and scheduled jobs run as functions alongside them. Tools like KEDA and Knative blur the line further, letting containers scale to zero and behave like functions when traffic disappears, while functions-in-containers approaches package FaaS-style code as a container image for portability.

When to choose each: common workload scenarios

The right choice usually falls out once you name the workload type.

APIs and web services with steady, predictable traffic tend to run more cheaply on containers, since serverless billing per request adds up fast at sustained volume.
Background workers and batch jobs that run briefly and irregularly are a natural fit for serverless, since you avoid paying for idle worker capacity.
ML inference on GPUs almost always needs containers, because serverless platforms rarely offer GPU access and long model load times clash with function timeout limits.
Event-driven pipelines and glue code, such as resizing an image after upload or forwarding a webhook, are close to the textbook serverless use case.
High-throughput services at scale typically favor containers on cost, since a constantly busy function costs more per unit of compute than a container running the same workload continuously.

CNCF’s State of Cloud Native Development survey data backs this pattern: containers are used by around 61% of backend developers as of Q1 2025, while serverless sits at around 20%, and the report notes serverless usage has drifted down over time as steady, high-usage workloads such as machine learning become less cost-effective under per-invocation billing.

How to choose: a practical checklist

Run through this before committing to either model.

Map your traffic pattern: is it steady, bursty, or mostly idle with occasional spikes?
Estimate requests per second, mean execution time, and peak concurrency under realistic load.
Check whether the workload needs to hold state or long-lived connections between requests.
Confirm compliance or data-residency requirements that might rule out certain managed services.
Assess your team’s skills: container and Kubernetes operations need different expertise than function deployment and event wiring.
Ask your platform or provider about SLA guarantees, cold-start behavior, and what a migration path off their platform actually looks like.

On containers, Kubernetes usage sits at around 61% among backend developers as of Q1 2025, compared to around 20% for serverless, a gap that signals containers remain the default for most production backends even as serverless holds a durable niche.

Red flags worth stopping for: hard dependency on provider-only APIs with no abstraction layer, cold starts with no mitigation plan for latency-sensitive paths, and observability that stops at basic logs with no distributed tracing.

Practical notes from architecture reviews

Architecture reviews tend to reveal the same pattern: teams reach for serverless because it looks simpler to start, then hit walls once traffic becomes steady or the workload needs state. A senior-led review at the start, rather than mid-build, is usually what catches this before it becomes a rewrite.

For teams running containers in production, a few practices consistently pay off: GitOps for deployments so cluster state matches a version-controlled source of truth, a deliberate provisioned concurrency strategy rather than an afterthought, and CI/CD pipelines that build and scan images before they ever reach a cluster. Data-sovereignty requirements also shape the decision more than most teams expect. Swisscom’s Kubernetes Service is a case in point: it was built as a vendor-agnostic, compliant alternative to hyperscaler-managed Kubernetes, supporting production workloads at scale for organizations that need to keep infrastructure onshore. Ampersand has run similarly demanding operational setups, including a multi-site platform serving over 600 websites from a single system, where operational consistency mattered more than any single scaling decision.

How Ampersand helps teams pick and build the right architecture

Choosing between serverless and containers is rarely a one-time decision, it shapes your costs and your team’s workload for years. Ampersand runs architecture reviews with senior engineers involved from the first conversation, so the recommendation you get is tied to your actual traffic patterns and team skills, not a default answer.

If you already know you need a build, whether that is a new platform, a migration off a legacy system, or an integration layer connecting containers and managed services, Ampersand scopes the work as a fixed-scope project or an ongoing engagement. For teams that want architecture decisions reviewed continuously rather than once, ongoing technical support plans are available. Current details on packages and pricing are on the pricing page. Full details on packages and pricing are on the pricing page. Start with a conversation about your workload, and the right architecture usually becomes obvious well before any code gets written.

Sources

FAQ

Is serverless cheaper than containers?

It depends on traffic pattern: serverless is usually cheaper for intermittent or bursty workloads since you pay per request and execution time, while containers are usually cheaper for steady, high-volume traffic since you are not paying a per-invocation premium. CNCF survey data shows containers remain the more widely used option among backend developers overall.

Can Kubernetes scale like serverless does?

Kubernetes’ built-in Horizontal Pod Autoscaler scales replicas on a sync interval using CPU, memory, or custom metrics, which is slower and coarser than function-level scaling. Tools like KEDA extend this to react to external event sources such as queue depth, closing much of the gap with serverless elasticity while keeping workloads in containers.

How do I avoid vendor lock-in with serverless?

Serverless functions are built against a specific provider’s event formats and APIs, so full portability is difficult, though you can limit exposure by keeping business logic in shared libraries separate from the handler code. Containers avoid most of this problem since an OCI image runs on any compatible runtime, including a sovereign platform such as Swisscom’s Kubernetes Service.

Do cold starts always matter for serverless?

Cold starts matter most for latency-sensitive, user-facing requests, less so for background jobs or asynchronous processing where a short delay is invisible to the user. Provisioned concurrency reduces cold starts by keeping execution environments pre-initialized, at an added cost that scales with how much concurrency you reserve.

Have a project this touches on?

A free 10-minute call is the fastest way to find out whether we are the right studio for it.

Book a free 10-min call

Keep reading