The name is misleading
Serverless computing does not mean there are no servers. Servers still run your code. The word means that you do not provision, patch or manage those servers yourself. The provider decides where your code runs, starts it when needed, and deals with the machines underneath.
From the customer’s point of view, you hand over a piece of code and describe when it should run. Everything about the machines is out of sight.
How it typically works
The most familiar form is often called “functions as a service”. You write a small function that does one job, such as resizing an uploaded image or sending a confirmation message. Then you attach a trigger, an event that causes the function to run. Common triggers include:
- a web request arriving
- a file being uploaded to storage
- a new message appearing in a queue
- a database record changing
- a scheduled time, like every night at 2 a.m.
When the event happens, the provider starts your function, runs it, and then stops it. If a hundred events arrive at once, it can generally start many copies in parallel. When nothing happens, nothing runs.
Triggers and functions often talk to other services through an API, so some grasp of API basics is useful here.
Where the term is also used
“Serverless” is also applied to other managed services where you do not pick or size servers, such as some databases, queues and storage products. The shared idea is the same: capacity adjusts automatically and you are charged for what you use. When reading a provider’s documentation, check what exactly is meant by the word for that product.
Why people use it
Less operational work. There is no operating system to update and no server fleet to watch. Tasks like patch management on those machines belong to the provider.
Scaling that follows demand. Capacity generally grows and shrinks automatically, with little configuration.
Pay-per-use pricing. Billing is typically based on how many times code runs and for how long, plus the resources used, rather than on a server running around the clock. For work that happens occasionally, that can be very economical.
Fast to start. A small function can be live quickly, which suits prototypes and glue between systems.
Where it fits well
- event-driven jobs such as processing uploads or reacting to messages
- tasks that run on a schedule
- small web back ends with uneven traffic
- lightweight automation, similar in spirit to task automation but running in the cloud
- connecting one service to another
Limits and trade-offs
Time and resource limits. Functions commonly have maximum run times and memory limits, so very long or heavy jobs may not fit.
Cold starts. If a function has not run recently, the first request may take longer while the environment starts. How noticeable this is depends on the platform and the workload.
Less control. You generally cannot choose the operating system or install anything you like. This is the other side of not managing servers.
Statelessness. A function does not remember anything between runs. Anything that must persist goes to a database or storage service.
Costs can still surprise. Pay-per-use is cheap at low volume, but constant heavy use can cost more than a continuously running server. A runaway loop, where a function triggers itself repeatedly, can generate a large bill quickly. This is a common reason to set budgets and alerts, as discussed under cloud costs.
Dependence on the provider. Functions often rely on a provider’s specific triggers and services, which makes moving them harder. That is the vendor lock-in question again.
Harder debugging. Many small pieces make it harder to follow what happened. Good system monitoring and system logs matter more, not less.
Where it sits among the service models
Serverless is usually placed near platform services in the cloud service models picture: the customer provides code and the provider runs it. It is more hands-off than renting virtual servers and, in practice, also more hands-off than packaging software containers and running them yourself, although some container services are offered in a serverless style too.
Security still matters
Not managing servers does not mean not managing security. Under shared responsibility, you still own your code, its permissions and its data. In particular:
- give each function only the access it needs, following least privilege
- protect secrets such as passwords and keys, and avoid placing them in code
- check inputs, since functions are often exposed to the internet
- keep track of third-party libraries your code depends on
Is it right for you?
Questions worth asking:
- Is the work made of short, separate tasks triggered by events?
- Is traffic uneven or unpredictable?
- Can the task finish within the provider’s time limits?
- Do we mind being tied to a particular provider’s way of doing things?
- Do we have a way to test, monitor and set spending limits?
If most answers are yes, serverless may be worth a small trial. If you have a steady, heavy workload or need fine control, a more traditional setup may serve better. Many organizations use both, with serverless for the small event-driven pieces around a larger system.