What is serverless computing? The concept explained

The name is a misnomer — and what it actually means

There are, of course, servers. Serverless code runs on physical machines in the provider’s data centres like everything else in the cloud. What the name captures is that the servers are no longer your concern in any way: you never choose them, size them, patch them, scale them or even see them. Your unit of thought moves up from “machines running my code” to simply “my code”.

Contrast the traditional model: with a virtual machine — Infrastructure as a Service — you rent a server and remain responsible for everything on it, paying for every hour it exists, busy or idle. Serverless inverts both halves of that deal. Responsibility for the environment passes entirely to the provider, and billing follows actual consumption: when nothing runs, nothing is charged. That combination — zero server management plus pay-per-use — is the definition worth remembering.

Functions as a Service, and the wider serverless family

The best-known form of serverless is Functions as a Service, and its best-known example is AWS Lambda. You write a function — a small piece of code that does one job — and upload it. The provider stores it, and when something triggers it, spins up an environment, runs it, and tears everything down again. If a thousand triggers arrive at once, the provider runs the function a thousand times in parallel without you configuring anything.

Serverless is broader than functions, though. The same deal — no servers to manage, pay for consumption — is offered by whole families of services: managed message queues, API gateways that receive and route web requests, serverless databases that scale storage and throughput automatically, and event and workflow services that connect the pieces together. A modern serverless application is typically a composition of these managed parts with functions supplying the custom logic between them.

The event-driven model

Serverless applications are naturally event-driven: code runs in response to things happening rather than sitting in a loop waiting. An event might be an HTTP request arriving at an API, a file landing in storage, a message appearing on a queue, a database record changing, or a schedule firing. Each event triggers a function; the function does its work — perhaps emitting events of its own — and exits.

This shape changes how you design software. Instead of one long-running application holding everything together, you get many small, independent pieces connected by events, each scaling on its own and failing on its own. That brings real architectural benefits — loose coupling, independent scaling, natural resilience boundaries — but it also means the logic of the system lives partly in the connections between components, which takes some getting used to if you have only ever built monoliths.

The genuine benefits

The serverless value proposition is straightforward and, for the right workloads, compelling:

• No capacity planning — the provider scales from zero to a flood of traffic and back without configuration, removing an entire category of guesswork.
• Scale to zero — an application with no traffic costs essentially nothing to keep deployed, which transforms the economics of low-traffic and spiky workloads.
• Granular cost — billing tracks actual execution, so cost maps to real usage rather than provisioned capacity sitting idle.
• Less operational burden — no operating systems to patch, no fleets to maintain, no scaling policies to tune; small teams operate systems that would otherwise need dedicated infrastructure effort.
• Faster shipping — with the undifferentiated plumbing handled, teams spend a larger share of their time on the logic that makes their product distinct.

The genuine drawbacks

Serverless has real costs, and honest ones are worth knowing before the exam or the architecture review. Cold starts: when a function has not run recently, the provider must create a fresh environment before executing it, adding latency to that first invocation — usually tolerable, but material for latency-sensitive paths. Execution limits: functions are designed for short-lived work and providers cap how long a single invocation may run, so long-running jobs need a different shape or a different service; check the provider’s documentation for current limits.

Development friction is real too: reproducing a cloud full of managed services on a laptop is genuinely harder than running one process, so local testing and debugging require more deliberate tooling. Functions are stateless — anything worth keeping must live in external storage, which the architecture must plan for. And a deeply serverless design composes many provider-specific services, which couples the application to that provider more tightly than a design built on plain virtual machines. Each of these is manageable; none of them is imaginary.

When to choose it, and where it appears in certification study

Serverless shines for event-driven and spiky workloads, APIs and web backends, scheduled and glue tasks, and any application where the traffic pattern is unpredictable or the team is small — the pay-per-use economics and absent operations work hardest there. It fits less well for long-running compute, ultra-latency-sensitive paths where cold starts bite, workloads with steady heavy utilisation (where provisioned capacity can be more economical), and systems being migrated as-is from traditional servers. The mature position is that serverless is a powerful default for new event-shaped work, not a universal answer.

In certification terms, serverless runs through the whole AWS path. The Cloud Practitioner expects you to know what serverless means and to recognise Lambda and its companions as serverless services. The Developer Associate leans on it hardest — Lambda, API-driven architectures and event-driven design are central to that exam — and the Solutions Architect Associate regularly frames scenarios where a serverless design is the best answer on cost or operational grounds. If the ideas here are comfortable, you have a head start on all three.