Serverless vs containers: which should you use?
Serverless and containers are two ways to run applications in the cloud — serverless lets a provider run your code on demand with no infrastructure to manage, while containers package your app to run consistently anywhere but leave you responsible for how and where they run. Neither is a strictly better choice; they trade operational effort for control in opposite directions, and the right pick depends on the shape of the workload rather than which technology sounds more modern. Increasingly, the two also blur together, since managed container services can remove much of the infrastructure burden that used to be the whole argument for going serverless. This guide defines each model, compares the practical trade-offs, and gives an honest answer on when to reach for which — plus where the choice shows up in architecture certification study.
What serverless is
Serverless computing — often built on functions as a service, or FaaS — lets you deploy individual pieces of code and have the provider run them in response to events, without you provisioning or managing any server yourself. Our explainer on what serverless computing is covers the model in full. The defining traits are that it is event-driven (a function runs in response to a trigger, such as an HTTP request or a file upload), it scales automatically, including down to zero when nothing is happening, and you pay per execution rather than for capacity sitting idle. The provider owns everything below your code: the operating system, the runtime, the scaling.
What containers are
A container packages an application together with everything it needs to run — code, dependencies, configuration — into a single portable unit that behaves the same wherever it runs. Our explainer on what Docker is covers the tool that popularised the format, and our explainer on containers vs virtual machines covers how containers differ from the older virtualisation model. Containers give you far more control over the runtime environment than serverless does, but that control comes with responsibility: you (or an orchestration platform such as Kubernetes) decide how many copies to run, how they scale, how they are networked and how they are deployed.
The key trade-offs
Set side by side, the two approaches pull in opposite directions on several axes:
- Operational overhead — serverless is minimal, since the provider manages the runtime; containers require you to manage orchestration, scaling and deployment, whether directly or through a platform.
- Control and flexibility — serverless is limited to what the provider’s runtime supports; containers give high control over the environment, dependencies and configuration.
- Scaling — serverless scales automatically and near-instantly, including to zero; containers scale according to whatever rules you or your orchestration platform configure.
- Cost model — serverless is pay-per-execution, which suits spiky or infrequent workloads; containers are typically pay-for-running-capacity, which suits steady, predictable load.
- Constraints — serverless functions usually have cold-start latency and maximum execution-duration limits; containers run continuously with no such caps, at the cost of always-on capacity.
- Portability — serverless functions often couple to a specific provider’s platform; containers are highly portable, since the same image runs consistently across clouds or on-premises.
When to choose each
Serverless suits event-driven, spiky or relatively simple workloads: processing an upload as it arrives, responding to an API call intermittently, running a scheduled task, or gluing other services together. Containers suit long-running, complex or stateful applications, workloads with heavy or unusual dependencies, and anything where portability across environments or clouds matters. Neither call is really about scale alone — a very large serverless workload and a very small containerised one both exist — it is about the shape of the traffic and how much control over the runtime the application genuinely needs.
The line is blurring
It is worth being honest that this is not a strict either/or choice in practice. Many architectures use both together — a serverless function handling a spiky API front door, backed by containerised services doing the heavier, longer-running work. Managed container services, such as AWS Fargate, further blur the distinction by removing the need to manage the underlying servers a container runs on, giving you container-level control without the traditional server-management burden that used to be serverless’s main selling point.
Where this appears in certification study
Choosing between compute models is central to associate-level architecture exams. The AWS Solutions Architect Associate and AWS Developer Associate exams both present scenarios that expect you to recognise when a workload calls for a serverless function versus a containerised or orchestrated service, and why. The Kubernetes and Cloud Native Associate exam goes deeper into the container-orchestration side specifically, covering how platforms like Kubernetes manage the operational work that serverless avoids by design.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.