Serverless Computing Explained: Trade-offs
Serverless computing lets you deploy code or managed services without choosing, patching or scaling a server yourself.
In this guide
The name is misleading: servers still exist, you just do not manage them. The provider runs your code in response to an event, scales it automatically and bills for the compute time you actually use.
That changes the economics for spiky or unpredictable workloads. It also changes the engineering, because a function is short-lived, stateless and constrained by the platform's limits.
Functions and managed backends
Functions as a service runs a handler when an HTTP request, queue message, file upload or schedule fires. Managed services extend the idea to databases, queues, authentication and storage, so a small team can run a real product without operating infrastructure.
The practical pattern is composition: a function handles one small piece, an event bus connects it to the next, and managed services hold state. Applications are built from many small units rather than one large server.
- Event sources: HTTP, queues, schedules, object storage, database changes.
- Compute: short-lived stateless functions with a maximum runtime.
- State: managed databases, object storage and key-value stores.
- Integration: event buses and workflow orchestration services.
- Delivery: edge functions for low-latency personalisation and routing.
Why teams choose it
Scaling is automatic, including scaling to zero, so a side project costs almost nothing when idle. There are no servers to patch and no capacity planning, which lets a small team ship quickly.
Because functions are small and event-driven, deployments are usually faster and blast radius is smaller. That makes serverless a good fit for APIs with uneven traffic, webhooks, image processing and scheduled jobs.
The trade-offs to plan for
Cold starts add latency when a function has not run recently, though provisioned concurrency and faster runtimes reduce this. Long-running or steady high-volume workloads are often cheaper on containers.
Per-function observability is harder than watching one server, so tracing and structured logging are mandatory rather than optional. Deep use of provider-specific services also raises the cost of moving later.
When to use it, and when not to
Choose serverless for event-driven APIs, glue between services, scheduled tasks, media pipelines, authentication hooks and prototypes where speed to launch matters more than unit cost.
Choose containers or virtual machines for steady high throughput, long-lived connections, custom runtimes or strict latency requirements. Many teams run both, using serverless for the edges and containers for the core.
Key facts at a glance
Frequently asked questions
Is serverless cheaper than running servers?
It is cheaper when traffic is low or spiky because you pay only for execution. At sustained high utilisation, reserved containers or servers are usually less expensive per request.
What is a cold start?
The extra latency when a platform must initialise a new execution environment before running your function, typically after idle time or a scale-up event.
Can serverless applications use a database?
Yes, but connection handling needs care because each function instance may open its own connection. Pooling services and HTTP-based database drivers solve most of the problem.