Serverless Compute
A small piece of application logic may run only when a request arrives or a file is uploaded. Keeping a server running solely in case that event happens wastes capacity and creates infrastructure work unrelated to the function.
Serverless compute moves provisioning, runtime maintenance, and capacity scaling to the provider. The application supplies code or a container plus a trigger.
Two Common Shapes
| Shape | Input boundary | Useful fit |
|---|---|---|
| Request-driven service | An HTTP request or message | Stateless APIs and web services |
| Event-driven function | A storage, queue, schedule, or other cloud event | Small reactions and workflow steps |
A request-driven container may run a complete service. A function is usually narrower and handles one event type or business step. The boundary matters more than the marketing label.
Event Flow
event occurs
→ platform selects and starts capacity
→ handler receives input
→ handler performs work
→ platform records completion or failure
The provider can scale the number of running instances up and down, sometimes to zero. Usage-based billing follows execution more closely than permanently allocated servers, although requests, storage, network transfer, and idle-instance settings may still have separate costs.
Where the Naive Model Breaks
It is tempting to treat each event as exactly-once work. In a distributed system, delivery can be delayed or repeated, and a timeout can hide whether the handler completed.
A robust handler should therefore:
- validate its event input;
- be safe to retry where possible;
- record durable state outside its disposable runtime;
- place limits on execution time and resource use; and
- expose failures so they can be retried or investigated.
Serverless removes server management from the developer's immediate workflow. It does not remove state, networking, security, or failure semantics.