Bry

Posted on Oct 6 Originally published at Medium

Serverless vs Containers: A Manager's Guide

#aws #webdev #cloud #devops

Key Points

Serverless reduces operational burden — your team writes code, not infrastructure. Containers give you more control, but someone has to own that control.
The cost winner depends on your traffic pattern, not your team's preference. Low or spiky traffic favors serverless. High, steady traffic favors containers.
If your application needs persistent connections or long-running processes, serverless cannot do the job. Containers win by default.
Most mature engineering organizations use both. Serverless handles events and background jobs; containers run the core API.
Start with serverless. Migrate to containers when you hit its limits — not before.

Introduction

Every engineering team reaches a moment where the architecture question becomes real: do we go serverless or do we run containers? The answer your engineers give will sound technical. The decision you make should be business-driven. I have sat in that room — first as the engineer making the case, later as the person holding the budget — and the framing that matters is almost never the one the engineers lead with. This is not a question of which technology is more sophisticated. It is a question of which model reduces your operational burden, matches your cost structure, and fits the expertise you have on the team today. The wrong choice does not break your product — but it does burn money and time that you cannot get back.

The Core Question

Engineering teams often frame this debate around technical elegance. That is the wrong frame for a leadership conversation.

The right questions are: How much of your team's time do you want spent managing infrastructure versus building product? What does your traffic look like — steady and predictable, or bursty and unpredictable? And what does your cost structure look like at the scale you expect to reach in 12 to 18 months?

Those three questions will do more to guide your decision than any benchmark comparison.

The Analogy That Makes This Clear

Think of serverless as hiring contract workers. When work arrives, they show up — instantly, in whatever number the job requires. When work stops, they go home and you stop paying. The tradeoff: each new contractor takes a moment to get oriented before they start producing (this is the "cold start" delay engineers worry about). For most workloads, that delay is imperceptible. For some, it matters.

Containers are more like full-time staff. They are always at their desks, warmed up, ready to respond the moment a request arrives. Performance is consistent and predictable. The tradeoff: you pay their salary whether they are busy or not. If your servers run at 10% capacity most of the day, you are paying full-time wages for part-time work.

Neither model is universally better. The right one depends on what your workload actually looks like.

What This Means for Your Team

The operational difference between these two approaches is significant — and it falls on your engineering team, not on you.

With serverless, your team does not manage servers, operating systems, or capacity planning. The cloud provider handles all of that. The result is a smaller operational burden, faster deployment cycles, and less specialized infrastructure expertise required. A team of three engineers can run a meaningful serverless application without a dedicated DevOps hire. The tradeoff is that debugging and monitoring are harder. There is no persistent process to inspect, no server to SSH into. Your engineers need to think differently about troubleshooting.

With containers, your team owns the runtime environment — which means they control everything, including the things that go wrong. This is powerful for complex applications with specific runtime requirements. It also means someone on your team needs to understand container orchestration: the tooling that runs, scales, and connects your containers across a fleet of servers. That is a real skill that takes time to develop and retain. In practice, I have seen teams underestimate this consistently — they provision containers, get them running, and then discover six months later that nobody owns the upgrade cycle or the on-call rotation for the orchestration layer. If your team already has the expertise, containers unlock significant capability. If they do not, you are taking on an infrastructure learning curve while trying to ship product.

A 2024 platform engineering survey found that organizations running container orchestration required an average of 2.5 dedicated platform engineers per 100 application developers. Serverless architectures required 0.5. That difference has a salary cost.

The Cost Model Without the Math

Both pricing models are simple in principle. Serverless charges per request and per millisecond of execution time. If no one is using your application, you pay nothing. Containers charge per running hour — the server is on whether requests are flowing or not.

The cost winner is almost entirely determined by your traffic pattern:

Traffic Level	Serverless	Containers
Low / spiky (under 1M requests/month)	Cheaper — you pay only for actual use	Wasteful — servers sit idle most of the time
Medium (1M–100M requests/month)	Competitive	Competitive
High / steady (over 100M requests/month)	Can get expensive	Cheaper — cost amortized across constant load

A useful real-world reference point: a nightly batch job that runs two hours per day costs roughly a third less on serverless than on a dedicated container. A high-volume production API serving 500 requests per second costs roughly half as much on containers. The inflection point is utilization — how much of your provisioned capacity you are actually using at any given moment.

One important nuance: serverless has hidden costs that do not appear in the headline pricing. API gateways, data transfer, and third-party integrations all add to the bill. Factor these in before drawing conclusions from a back-of-napkin estimate. I recommend building a 90-day cost model that includes those line items before you take either option to a budget conversation — the headline number is almost always optimistic.

What Serverless Cannot Do

Serverless is not the right tool for every job, and knowing its hard limits will save you from an expensive architectural mistake.

Long-running processes. Most serverless platforms impose a maximum execution time of 15 minutes. If your application does anything that runs longer — large data processing jobs, video transcoding, complex ML inference — serverless will cut it off. Containers have no such limit.

Persistent connections. Serverless functions do not hold open connections between requests. If your application relies on WebSockets (live chat, real-time dashboards, multiplayer features) or long-lived TCP connections (certain financial data feeds, streaming protocols), serverless cannot support them. This is an architectural constraint, not a configuration option. I have seen this surface mid-project when a team built their real-time notification feature on serverless, got it working in testing, and then watched it fail immediately under a live user load that expected sustained connections — a costly rebuild two months before launch.

In-memory session state. Serverless functions are stateless by design. They do not remember anything between requests. Applications that rely on keeping data in memory across a user's session need a different approach — either an external cache or a stateful server, which points toward containers.

If your application requires any of these capabilities, containers are not just a preference. They are a requirement.

How Most Organizations Actually Do This

The serverless-versus-containers debate often presents as a binary choice. In practice, most mature engineering organizations use both — deliberately.

The common pattern: serverless handles everything event-driven and asynchronous. File uploads trigger a serverless function that resizes images and updates a database. Webhooks from payment processors invoke serverless logic that updates order status. Scheduled jobs run as serverless functions on a timer. None of this requires a persistent server.

Meanwhile, the core API — the service that handles user-facing requests in real time — runs in containers. It has predictable traffic, consistent performance requirements, and stateful session logic that makes serverless a poor fit.

This hybrid approach is not a compromise. It is a rational use of each tool where it performs best. If you are starting fresh, there is no rule that says you must choose one and abandon the other. I default to this split on greenfield projects: serverless for anything async and event-driven, containers for the core API — and revisit the boundaries only when cost data or a hard technical limit gives me a reason to.

Decision Flowchart

Use this to orient your conversation with your engineering team. It does not replace a proper architectural review, but it will tell you which direction to lean.

Adoption Roadmap

If you are moving toward either architecture deliberately — rather than inheriting whatever a previous team built — a phased approach reduces risk.

Phase 1 — Evaluate (Weeks 1–4). Map your existing workloads. Identify which are event-driven and short-lived versus long-running and stateful. Check your current monthly request volume and traffic distribution. Audit your team's infrastructure skills. This phase produces a recommendation, not a commitment.

Phase 2 — Pilot (Weeks 5–10). Choose one low-risk, non-critical workload and run it on the target architecture. A background job or an internal webhook handler is ideal. Measure actual cost against your estimate. Have your team document what was harder than expected.

Phase 3 — Expand (Months 3–6). Move additional workloads based on what you learned in the pilot. Establish internal patterns and templates so that each new workload does not require a new architectural conversation. Define your monitoring and alerting standards for the chosen model.

Phase 4 — Standardize (Month 6+). Codify the decision criteria your team uses. Document which workload types go serverless and which go containers. New engineers joining the team should be able to read one internal document and understand why things are built the way they are. That is the sign that the architecture is settled.

Questions to Ask Your Engineering Team

Before your team commits to an architecture, make sure you can get clear answers to these seven questions. If the answers are vague or contradictory, you need more time in Phase 1 before moving forward.

What does our traffic actually look like? Ask for a graph of requests per hour over the last 30 days. The shape of that graph — spiky or flat — is the single most important input to this decision.
Does our application need to hold open connections, and for how long? This determines whether serverless is technically viable, full stop. If the answer is yes, the discussion is over — you need containers.
Who on the team owns infrastructure, and what is their current skill set? If the answer is "nobody, really," that tells you something important about the operational risk of adopting containers. In my experience, this question surfaces the most organizational debt — teams that say they "use Kubernetes" but have one person who set it up two years ago and nobody who can troubleshoot it at 2 a.m.
What is our expected request volume in 12 months? Cost models diverge significantly at scale. An architecture that looks cheaper today may reverse at 50 million requests per month. Make sure the projection includes growth.
What is our tolerance for cold start latency? Serverless functions can take a fraction of a second to initialize when they have been idle. For most web APIs, this is invisible. For latency-sensitive applications — real-time bidding, financial transactions, gaming — it may be unacceptable.
Do any of our processes run longer than 15 minutes? ETL jobs, report generation, large file processing. If the answer is yes for any workload, that workload needs containers. It does not necessarily mean everything needs containers.
What does our current infrastructure bill look like, and what is it buying us? Understanding your baseline makes it possible to evaluate whether a new architecture is actually cheaper or just feels cheaper because it is new.

Conclusion

Serverless and containers are not rivals — they are tools with different strengths, suited to different conditions. The teams I have seen make this decision well are the ones who start from their actual workload and traffic data, not from what is trending at the time. Start with serverless if your team is small, your traffic is variable, and you want to minimize operational overhead. Move to containers — or add them alongside — when the data tells you to, not when someone in a conference room makes an argument that sounds good. The seven questions above are not a formality: if your engineers cannot answer them cleanly, you are not ready to commit to either architecture, and that is the most important thing to know before you approve a roadmap.

DEV Community