What is Serverless Computing? | AI Glossary

Start here

Serverless Computing in plain language

Servers still exist. The distinction is who operates them and what the application team configures. Functions triggered by events are one familiar serverless pattern; managed data and messaging services can also be serverless.

Pricing and scaling vary by product. Requests, execution, storage, networking and reserved capacity can have separate charges. Serverless does not universally mean no idle cost, instant startup or unlimited concurrency.

How it works

The visual guide

A file event starts a small job

Illustrative upload processing

Upload event
An uploaded file produces a processing request.
Function runs
Validate the request and create the required output.
Store + record
Save the result and mark the job as completed.

If delivery is repeated, check the job identifier before creating another result.

Delivery and retry behaviour depend on the event source. Design for duplicates where they are possible and route persistent failures for investigation.

Define the trigger and output
Specify the event format, required permissions and where results will be stored.
Configure operating limits
Check runtime, memory, concurrency and downstream capacity. Decide how errors and retries are handled.
Observe real executions
Track duration, failure rate and cost. Inspect failed jobs rather than assuming a deployed function is completing useful work.

Illustrative example · Fictional data

Generating a fictional document preview

Input: A synthetic PDF upload creates a preview job identified by its file version.
Process: The worker checks whether that version already has a completed preview. If not, it generates and stores one, then records completion.
Expected output: One preview associated with the intended file version, even when the same event is delivered again.
How to check it: Test repeated events, corrupt input and storage failure. A retried job must not silently overwrite a newer file’s preview.

Where it helps

Event-driven processing of uploaded files.
Scheduled small integration tasks.
Variable request workloads that fit the chosen service’s limits.

Serverless, virtual machines and containers

Virtual machine: Provides guest-system control with more operational duties.
Container: Packages an application; it can run on several hosting models.
Serverless: Shifts server operation to the provider. Some serverless services also accept container images.

Common pitfalls

Retries can duplicate work unless operations are designed accordingly.
Automatic scaling can overwhelm a database with limited capacity.
Long-running or specialised workloads may not fit the selected service.

Put the idea to work

Try it yourself

Sketch an upload worker with three cases: success, duplicate event and invalid file. Specify where each outcome is recorded and which cases are retried.

Common questions

Does serverless mean there are no servers?

No. The provider operates them; the application team works with a higher-level service interface. The team still chooses memory, timeout and concurrency settings, but does not patch operating systems, size fleets or manage capacity for each request. AWS Lambda, Azure Functions and Google Cloud Run are common examples.

Is serverless always cheaper?

No. Compare the workload and all related charges, including storage, networking and supporting services. It often suits spiky or low-traffic workloads because you pay per use. For steady, high-volume traffic, always-on instances or containers can work out cheaper.

Can a serverless application keep data?

Yes, through appropriate persistent storage. Do not assume a particular execution environment’s local state will survive subsequent invocations. Common choices include managed databases, object storage, queues and caches. Keep functions stateless and pass state explicitly so any instance can handle the next request.

Your next step