Serverless Computing: What You Trade Away
Serverless removes the server and adds a different set of problems: cold starts, execution limits, local development and a bill that scales with traffic. When that trade is worth making.
The short version
- Serverless does not remove operational work. It replaces server operations with distributed systems operations, which is not obviously simpler.
- It is excellent for spiky, event-driven and genuinely intermittent workloads, and expensive for steady high-volume traffic.
- The database connection model is the constraint that catches most teams, and it needs solving before you write the first function.
- The strongest case is not cost. It is scale-to-zero for workloads that are idle most of the time.
Serverless has been through the full hype cycle and come out the other side as a normal tool with a defined set of good uses. That is a better place to be than either the “servers are obsolete” period or the backlash that followed it.
What follows is what the trade actually consists of.
What you genuinely get
Scale to zero. An idle function costs nothing. For workloads that run occasionally — a nightly report, a webhook receiver that fires forty times a day, an internal tool used by six people — this is transformative compared with a server running twenty-four hours a day to be available for four minutes of work.
Automatic scaling. A traffic spike is handled by the platform running more instances. No capacity planning, no autoscaling group tuning, no scramble when a campaign lands. For genuinely unpredictable load this is worth a lot.
No server maintenance. No patching, no operating system upgrades, no capacity monitoring. The platform’s problem.
Fast to start. A function, an event trigger, deployed. For a small piece of glue between two systems, the distance from idea to production is genuinely short.
What you trade away
Cold starts
A function that has not run recently needs an execution environment created before it can handle a request. The penalty ranges from tens of milliseconds to several seconds depending on runtime, package size and whether the function is inside a private network.
Runtime choice matters more than people expect. Compiled languages and lightweight runtimes start fast; heavy frameworks with large dependency trees and just-in-time initialisation start slowly. If your function loads a hundred megabytes of libraries before doing anything, you have chosen the slow path.
Mitigations exist — provisioned concurrency, keeping deployment packages small, avoiding unnecessary private network attachment — but provisioned concurrency in particular is worth noting: paying to keep instances warm removes the main economic argument for serverless in the first place.
Execution limits
Maximum duration, maximum memory, maximum payload size, maximum concurrent executions. Every platform has them and they are lower than you would like.
The consequence is architectural rather than incidental. Anything long-running must be decomposed into steps coordinated by a state machine or a queue. That is sometimes a better design anyway and sometimes an accidental distributed system solving a problem a single process handled fine.
Database connections
This is the one that catches teams, and it is worth understanding before writing any code.
Traditional databases assume a small number of long-lived connections from a known set of application servers. Serverless produces the opposite: many short-lived instances, each wanting its own connection. Under load, a few hundred concurrent function instances will exhaust a database connection pool immediately.
The answers are a connection proxy such as RDS Proxy or PgBouncer, a database with an HTTP-based data API, or a serverless-native database designed for the pattern. All of them work. What does not work is discovering the problem during your first traffic spike.
Decide the connection strategy first. More serverless projects have been derailed by connection exhaustion than by cold starts, and unlike cold starts it fails suddenly and completely rather than gradually.
Local development and testing
Running the platform on your machine is always an approximation. Emulators exist and are imperfect, particularly around permissions, event shapes and timing. Teams end up testing against real cloud resources, which is slower, costs money and complicates working on several branches at once.
Observability
A request that touches six functions, two queues and a state machine produces a distributed trace rather than a stack trace. Distributed tracing is not optional here, it is the only way to understand what happened, and it has to be set up deliberately from the start.
The cost picture
The economics are the most misunderstood part, so it is worth stating plainly.
Serverless bills per invocation and per unit of compute time. For low or intermittent volume this is dramatically cheaper than a server, often to the point of being free. As sustained volume rises there is a crossover, after which a small always-on instance is cheaper — sometimes by a large multiple.
Where that crossover sits depends on your request duration and memory allocation, but the shape is reliable: serverless is cheap when idle and expensive when saturated. A service handling steady high traffic around the clock is close to the worst case for the pricing model.
Two secondary costs are routinely forgotten. Data transfer, particularly between availability zones, appears on the bill and surprises people. And a bug that causes a function to retry in a loop can generate a genuinely alarming invoice overnight, which is why concurrency limits and billing alarms belong in the initial setup rather than the backlog.
Where it fits well, and where it does not
Good fits: event processing, where something happens and code should run; scheduled jobs, replacing a server that exists to run cron; webhook receivers, which are spiky and intermittent by nature; image and file processing triggered by uploads; internal tools with a handful of users; and glue between services, where the alternative is a whole deployment for fifty lines of code.
Poor fits: sustained high-traffic APIs, where cost and cold starts both work against you; long-running computation that exceeds execution limits; anything needing persistent connections such as WebSockets, unless the platform has a dedicated mechanism; latency-critical paths where a cold start is unacceptable; and applications with heavy local state.
The hybrid answer
The framing that has aged best is not choosing serverless as an architecture but using it where it fits inside a normal one.
A container or a server handles the main application, where traffic is steady and cost per request is low. Functions handle the spiky edges: the image resizer, the webhook endpoint, the nightly export, the occasional heavy background job. Each part uses the model that suits its load profile.
That is less tidy than a single answer and it is what most well-run systems converge on.
Boolean Solutions experience with serverless
We build and operate both, and our advice is consistently to start from the load profile rather than the architecture. Traffic that is spiky, intermittent or unpredictable suits functions. Traffic that is steady suits a server, and a modern single server handles far more than most teams assume.
The regret we see most often is a team that adopted serverless everywhere for operational simplicity, then discovered they had traded server operations for distributed systems operations at a point in their growth when they had capacity for neither. If you are weighing this up for a new service, we are happy to look at the numbers with you, and our DevOps services page covers how we approach the operational side.
Further reading
- Serverless Architectures — Mike Roberts on martinfowler.com; long, thorough, and still the best single overview
- AWS Lambda Operator Guide — the practical operational detail, including cold starts and concurrency
- Serverless cost calculator — worth running your real numbers through before committing
- RDS Proxy — the standard answer to the connection problem
Udit Mittal
Founder at Boolean Solutions. Twenty years of building and rescuing web, mobile and AI products for SaaS companies and startups — and writing down what actually worked.
Get in touch
