The name is misleading
“Serverless” sounds as if no servers are involved. In reality, the code still runs on servers in a data center. What changes is who deals with them. In a serverless model, the cloud provider handles the servers, the operating system, scaling and much of the routine maintenance. The customer writes the code and decides what should trigger it.
A more accurate description might be “server-management-free” from the customer’s point of view. The servers have not disappeared; they have been moved out of sight.
How it works
The most common form is often called functions as a service. You write a small piece of code, a function, that does one job, such as resizing an uploaded image or sending a confirmation email. You upload it to the provider and specify what should trigger it. Triggers might include:
- a web request arriving at an address
- a file being added to storage
- a message appearing in a queue
- a scheduled time, like every night at midnight
- a change in a database
When the trigger occurs, the provider finds spare capacity, starts an environment (often a lightweight sandbox related to software containers), runs your function, returns the result, and later shuts the environment down. If a thousand triggers arrive at once, the provider starts many copies in parallel. If none arrive, nothing runs.
Beyond functions, the term is also used for managed services where you do not provision servers, such as some databases and storage services that scale automatically.
How it differs from other models
In the infrastructure model, you rent virtual machines and keep them running. They sit there, and are billed, whether busy or idle. In a platform model, you deploy an application that the provider hosts, though it is typically running continuously. Serverless goes a step further: your code runs only when needed. The differences among these packages are covered in cloud service models.
A rough analogy is the difference between owning a car, renting one by the day and taking a taxi. With the taxi you pay for each trip and never think about parking or maintenance, but each trip has its own booking and wait.
Typical benefits
- Less operations work. No patching of operating systems or capacity planning for the underlying servers.
- Automatic scaling. Capacity follows demand, up to provider limits.
- Pay for use. Billing is typically based on the number of runs and how long and how much memory each uses, so idle time generally costs little or nothing. For unpredictable or occasional workloads, this can be economical.
- Fast to start. Small projects can go live without setting up infrastructure.
- Good fit for event-driven tasks. Short jobs triggered by events suit the model well.
Typical drawbacks
- Cold starts. If a function has not run recently, the first call may need extra time to set up its environment, causing a noticeable delay. Providers work to reduce this, and its impact varies, but it can matter for tasks where network latency is already a concern.
- Time and resource limits. Functions usually have maximum run times, memory sizes and package sizes. Long-running or very heavy jobs may not fit.
- Statelessness. A function should not rely on remembering anything between runs. Data must be kept in external storage, such as a database, so design needs care.
- Cost at scale. For steady, high-volume workloads, pay-per-use can end up costing more than running dedicated servers. A careful comparison is needed, using real usage figures.
- Vendor lock-in. Triggers, configuration and surrounding services differ between providers, so moving can take work.
- Harder debugging and testing. The environment is not directly under your control, and applications made of many small functions can be difficult to trace.
- Dependence on the provider. If the platform has trouble, as described under cloud outages, your functions may stop with it.
Where it fits well
- image or video processing triggered by uploads
- small web interfaces and form handlers
- scheduled tasks such as reports or cleanup jobs
- reacting to messages from IoT devices
- connecting services together through an API, the kind of interface described in API basics
- handling occasional spikes in traffic
Where it fits poorly
- applications needing constant, predictable heavy computation
- tasks requiring very low and consistent delay
- long-running processes
- systems with unusual hardware or operating system requirements
- software that must keep a lot of state in memory
Security responsibilities
Even in serverless, security remains shared. The provider secures the underlying platform, but you remain responsible for your code, the permissions you grant to functions, and your data. Giving a function only the access it needs is a standard precaution, and flaws in the code or in third-party libraries it uses can still be exploited. Mistakes with access settings are a common contributor to data breaches in cloud environments generally.
Putting it together
Serverless is best understood as a trade: you give up some control and accept the provider’s rules, and in return you avoid managing machines and pay mostly for actual use. It is a useful option, not a replacement for every other approach, and many systems mix serverless pieces with traditional servers and virtual machines. The right choice depends on the workload’s size, pattern and need for control.