Contents
Serverless is a model where you upload a function's code and the cloud runs it on events, scales it and bills you only for execution time. It pays off for uneven load, background jobs, file processing and integrations. A main web application with steady traffic is usually cheaper and simpler to run in containers on ordinary servers.
Here is how serverless works, which tasks it suits, how to estimate its cost and what its pitfalls are.
What is serverless?
Serverless means cloud services where you do not manage servers: you do not pick their size, patch the OS or configure scaling. The servers exist, of course, but the provider runs them, and you pay for the work actually done.
Serverless includes:
- cloud functions — code triggered by an HTTP request, a schedule or an event;
- serverless containers — your container, started only when requests arrive;
- managed databases and queues billed per operation rather than per server;
- object storage and event processing services.
Which tasks does serverless suit?
Serverless suits tasks that are event-triggered, run quickly and have uneven load: thousands of calls by day, zero at night. In these cases you do not pay for an idle server and scaling happens automatically.
| Task | Serverless? | Why |
|---|---|---|
| Processing uploaded images | Yes | Event-triggered, short execution |
| Webhooks from payment systems and CRMs | Yes | Uneven event flow |
| Scheduled jobs | Yes | No always-on server needed |
| A landing page with a lead form | Yes | Rare requests |
| A main API with constant load | Usually not | Containers are cheaper for steady traffic |
| Long computations and WebSocket | No | Time and connection limits |
Photo: Unsplash
How do you estimate serverless cost?
Serverless cost is based on the number of invocations, execution time and allocated memory. With low, uneven traffic it is almost free; with constant high load the bill can be several times more than a couple of ordinary servers.
How to estimate:
- Count monthly invocations and average execution time.
- Multiply by the per-invocation price and the price per gigabyte-second of memory.
- Add egress traffic, logs, the API gateway and managed databases.
- Compare with the price of containers or virtual machines for the same load.
- Model ten-fold growth — that is often where serverless stops paying off.
On choosing between your own server and the cloud, see VPS, cloud or managed services.
What are the pitfalls of serverless?
The main pitfalls are cold starts, runtime limits, debugging complexity and vendor lock-in. Account for them before choosing the architecture, not after launch.
- cold start — the first call after idle time can take hundreds of milliseconds or seconds;
- limits — maximum execution time, package size, memory and temporary disk;
- database connections — thousands of parallel functions quickly exhaust the connection limit, so a pooler is needed;
- debugging — a chain of functions is hard to reproduce locally; good logs and tracing are essential;
- vendor lock-in — triggers, permissions and services differ in every cloud.
More on logs and tracing in monitoring and logging.
Serverless or containers?
For most products a hybrid makes sense: the main application runs in containers, surrounded by cloud functions for background jobs, file processing and integrations. You get predictable cost for the core and flexibility where load spikes.
Choose containers if:
- traffic is steady and predictable;
- you need long-lived connections, WebSocket or heavy computation;
- it matters that the project can run with any provider or on your own server.
Choose serverless if:
- load is spiky or rare;
- tasks are short and event-triggered;
- the team does not want to deal with servers at all.
On containers and orchestration, see Docker for development and production and do you need Kubernetes.
In short
- With serverless the cloud runs and scales your code, and you pay for execution.
- It pays off for events, background jobs and uneven load.
- With constant high traffic, containers are usually cheaper.
- Consider cold starts, runtime limits, database connections and vendor lock-in.
- A common sweet spot is a containerised core with functions for peripheral tasks.
FAQ
Can a whole project be built on serverless?
Yes, and for small projects with uneven load it can pay off. But with constant high load, long requests and complex logic, ordinary containers are often cheaper and easier to debug.
Do Russian cloud providers offer serverless?
Yes, major Russian cloud providers offer cloud functions, serverless containers and pay-per-use databases. Feature sets differ, so compare them for your task.
How do you debug cloud functions?
Locally with the provider's emulators and ordinary unit tests of the business logic. In the cloud with structured logs and tracing — without them, a chain of functions is very hard to untangle.
