Serverless is a cloud model where the provider runs the servers for you. Servers still exist, but you never provision, patch or scale them. You deploy code or use a managed service, and you pay for the work it does rather than for idle machines. Function as a Service (FaaS), such as AWS Lambda, is the best-known form. This note explains the model, its trade-offs and when it fits.
What the provider takes over#
With virtual machines you manage the OS, scaling and uptime. Serverless moves all of that to the provider.
- Provisioning and capacity: the platform finds compute when work arrives.
- Scaling: it adds capacity as requests grow and removes it when they stop, often down to zero.
- Availability: it runs your code across multiple Availability Zones by default.
- Patching: the OS and runtime get security updates without your involvement.
- Billing: you pay per request and per unit of compute time, not per hour of uptime.
Serverless is wider than FaaS. Amazon S3, DynamoDB, SQS and Fargate are also serverless: you use them without managing any servers. FaaS is the part that runs your own code.
Units of scale#
Another way to see serverless is as the end of a trend. Each step from VMs to functions hides one more layer and shrinks the unit you deploy and scale.
| Model | Unit of scale | What it hides from you |
|---|---|---|
| Virtual machines | A whole machine | The physical hardware |
| Containers | An application | The operating system |
| Functions (FaaS) | A single function | The language runtime and server process |
A smaller unit means finer-grained scaling and billing. It also means less control over the machine underneath.
How FaaS works#
With the general model in place, here's how the FaaS part runs your code. You write small functions that each do one job. The platform runs a function when an event arrives. This is a reactive, event-driven design: nothing runs, and nothing is billed, until something happens.
An event can come from almost any AWS service. These are the common triggers:
| Trigger | Example |
|---|---|
| HTTP request | API Gateway or a function URL calls a function per request |
| Object storage | A PUT into an S3 bucket starts an image-resize function |
| Database change | A DynamoDB stream delivers new or changed items |
| Queue or stream | Messages on SQS or records on Kinesis are processed in batches |
| Schedule | An EventBridge rule runs a cleanup function every night |
Each invocation gets the event as input, runs, and returns. The platform may run many copies in parallel when events arrive faster than one copy can handle them. See AWS Lambda for how one platform does this in detail.
Because each function does one job, functions fit naturally with microservices. Each function is small, independent and stateless, and you can update one without touching the others. They often sit behind an API gateway or consume from a queue.
Benefits#
Most of what you gain traces back to the first section: you don't own the servers.
- No servers to manage: no OS patching, capacity planning or instance replacement.
- Continuous scaling: capacity follows the event rate automatically.
- No paying for idle: a function that gets no traffic costs close to nothing.
- Less operational work: teams spend more time on business logic and ship faster.
- Built-in availability: the platform handles zone failures for you.
Drawbacks#
The same abstraction that removes work also removes control.
| Drawback | What happens | Common mitigation |
|---|---|---|
| Loss of server tuning | You cannot pick kernel settings, hardware or network tuning. | Use VMs or containers for workloads that need it. |
| No in-server state | Each invocation may run on a fresh copy; memory is not shared between copies. | Keep state in a database, cache or object store. |
| Cold starts | A new copy must load the runtime and your code before the first request. | Keep packages small; use pre-warmed capacity where offered. |
| Vendor lock-in | Triggers, permissions and event formats are provider-specific. | Keep business logic in plain modules; isolate provider glue. |
| Execution limits | Functions have a maximum run time and memory size. | Split long work into steps or use containers. |
| Harder debugging | Requests cross many small functions and managed services. | Use structured logs and distributed tracing. |
Cost can also turn against you. For a service with high, steady traffic, paying per request can exceed the cost of a few always-on instances. Compare both before you commit.
Statelessness in practice#
Of the drawbacks in the table, statelessness is the one that most changes how you write code. A function cannot keep a user's session or a shopping cart in memory between calls, because the next call may land on another copy. Store that state outside the function, in a database such as DynamoDB or a cache such as Redis. This adds a network call, but it is also what lets the platform scale functions freely.
When to use it#
Weighing those benefits and drawbacks gives a clear pattern. Serverless fits work that is event-driven, bursty or small.
- Event processing: react to file uploads, database changes or queue messages.
- HTTP APIs with uneven or unpredictable traffic.
- Scheduled jobs: nightly reports, cleanups, data syncs.
- Glue code between managed services.
- Prototypes and low-traffic tools, where paying for idle servers is wasteful.
Prefer VMs or containers for long-running processes, steady high-throughput services, workloads that need special hardware or OS tuning, and latency-critical paths that cannot tolerate cold starts.
Key takeaways#
- Serverless means the provider runs and scales the servers; you pay for work done, not idle time.
- FaaS runs small, stateless functions in response to events such as HTTP calls, uploads and queue messages.
- The unit of scale shrinks from machine (VM) to application (container) to function (FaaS).
- Main drawbacks: no server tuning, no in-memory state between calls, cold starts and vendor lock-in.
- Serverless suits bursty, event-driven and glue workloads; steady heavy traffic may be cheaper on servers.