Serverless and event-driven computing

Serverless computing hands the provider every decision about machines: how many, how large, when to start and stop them. The developer supplies small units of code, called functions, and says which events should run them. A file lands in storage, a message joins a queue, an HTTP request arrives, a schedule fires; a function runs, finishes and leaves nothing idling behind it. Billing follows the same grain, charging for work done rather than for capacity kept waiting. AZ-900 lists serverless beside the consumption-based model among its cloud concepts, which is where the two ideas belong together.

Events, queues and the glue between them

Functions are the visible part; the design effort goes into how they connect. Event-driven systems pass messages through managed queues, publish-and-subscribe topics and event buses, so that the service raising an event need not know who reacts to it. The CNCF landscape guide explains the payoff: publishers and subscribers can change independently, and a new consumer can be added without touching code upstream. Longer processes are coordinated by workflow services that call functions in order and handle retries. In that sense serverless is PaaS pushed to its limit, with the platform hiding even the application server.

• Function: a short-lived unit of code, sized by memory and a time limit, started by an event.
• Trigger: the event source, such as a storage upload, a queue message, an API call or a timer.
• Queue and topic: a buffer that decouples producers from consumers, and a channel that fans one message out to many.
• Cold start: the delay while the platform prepares a fresh environment before running code.
• Idempotency: writing a handler so that processing the same event twice does no harm, since retries happen.
• Permissions per function: each function gets its own narrow role, which makes least privilege practical and forgetting it costly.

What the exams test and where to go next

The SAA-C03 blueprint asks candidates, across its resilience, performance and cost domains, to decide when serverless patterns fit, to design event-driven and loosely coupled systems with queues and API front doors, and to size a function's memory to a requirement. It also lists container services that run without a visible cluster among its serverless technologies. DVA-C02 examines functions and event-driven design from the developer's desk, and AWS's free Serverless knowledge badge is a gentler proof of the vocabulary. The beginner's mistake is to start with the function and invent the events afterwards; sketch the flow of events first and the functions follow from it. For comparison with packaged long-running services, read containers and Kubernetes; for why the bill can surprise, cloud cost and FinOps; and for following one request across many functions, operations and observability.