Serverless
Beginner 13 min read Serverless

FaaS & Cloud Functions

Handlers in, events out, no servers to pet

Function-as-a-Service runs single-purpose handlers on ephemeral compute: AWS Lambda, Azure Functions, Google Cloud Functions/Cloud Run. You write code, the platform owns servers, scaling, and runtime patches.

FaaSLambdaAzure FunctionsCloud Functionsserverlessfunction runtime
Prerequisites: Cloud Service Models
Before we start

What you will learn

  • Explain what FaaS manages on your behalf
  • Map event sources to function invocations
  • Pick Lambda vs Cloud Run vs Azure Functions by criteria
In 60 seconds

Upload code + set memory/timeout/role; the platform cold-starts an isolated runtime, feeds it an event, collects the return (or streams it), then recycles. Billing is per invocation × duration × memory.

Introduction

What is this?

Runtime model: 1 function = 1 handler(event, context). Isolation/environment: Lambda execution environments + IAM role; Azure function host plan + App Service identity; Cloud Run = container per revision, scale-to-zero. Triggers: S3 events, API Gateway/Front Door, queues (SQS/Kafka/Pub/Sub), DB streams (DynamoDB CDC), cron (EventBridge Scheduler). Lifecycle: deployment = new function version/revision; aliases route traffic; concurrency = 1 concurrency unit per active env.

Motivation

Why do you need it?

  • Zero idle cost — pay only when invoked.
  • No instance management: patching, autoscaling, capacity are the platform's job.
  • Event integration velocity: wiring S3→function takes minutes, not pipeline days.
  • Scaling is elastic and near-instant within platform concurrency budgets.
Think about it

Mental model

Imagine

A ride-hail car that lets anyone book a ride for just one trip

Think of

FaaS invocation

You describe the trip (event), a nearby car appears (warm env/invocation), takes you (executes), and leaves. You're never billed for the idle garage (no idle servers).

Mechanics

How it works

  • An event source (API, object write, cron) produces an invocation record.
  • Platform picks or warm-starts an execution environment with your handler + role.
  • Handler receives the event and returns a response or writes side effects.
  • Metrics/logs flow to observability; cold starts surface as latency spikes.
  • Environment returns to the pool; concurrency limits shape the scaling ceiling.

A function invocation.

Event source
Runtime
Handler
Response/side effects
Teardown
Hands-on

Examples

A thumbnail handler shape

A thumbnail handler shape
export async function handler(event) {
  const key = event.Records[0].s3.object.key;       // trigger payload
  const img = await readFromBucket(key);
  const thumb = processImage(img);
  await writeToBucket(key + "-thumb.jpg", thumb);
  return { statusCode: 200, body: key };
}

The function is a pure event→effect unit. The platform supplies the runtime, the role, and the scaling around it.

Real world

In production

  • Image/video processing pipelines keyed on bucket object puts.
  • Lightweight HTTP backends under API Gateway/Function App hosting.
  • Scheduled jobs (ETL triggers, report generation) via cron-like triggers.
  • Stream consumers scaling on Kinesis/Kafka/Pub/Sub partitions.
Guidelines

Best practices

  • Keep handlers small and single-purpose; one function per distinguishable trigger path.
  • Design for at-least-once: make handlers idempotent.
  • Give each function the minimum IAM role — no omnipotent lambdas.
  • Set explicit memory/timeout; measure before dialing up spending.
  • Use provisioned concurrency only where p95 latency is sacred.
Watch out

Common mistakes

  • Tuning memory blindly — CPU≠memory, both bill at once.
  • Stateful functions (storing data in /tmp) pretending to be stateless.
  • Functions that sleep/retry inside the handler, doubling duration bills.
  • One mega-function doing everything, making deploy blast radius huge.
When things break

Debugging tips

  • Check log groups per function for the platform's lifecycle markers (START/REPORT).
  • Compare cold-start count and duration across a release: init vs invoke time.
  • Use X-Ray/App Insights/trace to separate platform warm-up from business code.
  • Test the handler locally with the platform's event payload shapes before deploy.
Interviews

Interview checkpoint

Practice

Hands-on lab

Trigger Your First Function from an Object Write
40 min · beginner
In progress
Objectives
  • Deploy a simple handler listening on an object event
  • Upload a file and see an invocation + log line
  • Understand event payloads and IAM minimum-scope

Trigger Your First Function from an Object Write

40 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

FaaS is billed primarily by:

2

The platform, not you, owns:

Go deeper

Official documentation

AWS Lambda docs
docs
Azure Functions docs
docs
Cloud Run Overview
docs