Cloud Fundamentals
Intermediate 14 min read Cloud Fundamentals

Serverless Computing

Serverless lets you run code without provisioning servers: functions scale from zero, bill per invocation and hand the platform all infrastructure concerns. Learn how FaaS works, what cold starts cost, and when to choose serverless over containers.

serverlessFaaSLambdacold startscale-to-zeroevent-drivenpay-per-invocationtimeout
Prerequisites: Cloud Computing Fundamentals
Introduction

What is this?

Serverless computing runs application logic without you managing servers. Functions-as-a-Service (AWS Lambda, Azure Functions, Google Cloud Functions) execute a unit of code in response to an event, scale automatically to any concurrency, and bill only for compute time used. 'Serverless' also covers managed services like queues, databases and API gateways where the platform absorbs the operational burden.

Motivation

Why do you need it?

  • Scale-to-zero means you pay nothing when nothing happens — ideal for spiky and event-driven workloads.
  • There is no OS to patch, no cluster to size and no capacity planning; the platform handles it.
  • Event-driven architecture pairs naturally with queues, buckets and pub/sub topics.
  • Cold starts and execution limits are real constraints you must design around.
  • Serverless is a prime candidate for 90% of backend APIs — knowing when it is wrong is equally valuable.
Think about it

Mental model

Imagine

Renting a kitchen by the meal

Think of

Serverless functions

A restaurant kitchen (server) costs money while idle and must be sized for the busiest night. Serverless is like renting a prep station only when an order arrives — you pay per dish cooked, the equipment appears in milliseconds, and if a thousand orders arrive at once, the platform opens a thousand prep stations automatically.

Mechanics

How it works

  • You deploy a function (code plus a runtime, memory size and timeout) to the platform, which packages it into a container-like execution environment.
  • A trigger — API request, storage event, queue message, scheduled cron — invokes the function by creating an execution instance.
  • The platform provisions a sandbox for the invocation; if none is warm, it boots one (the cold start).
  • Concurrency is handled by the platform: many events spawn many instances, each isolated, and idle instances are recycled after a few minutes.
  • Billing accumulates per request and per compute-seconds (rounded to 1ms), so the same code costs nothing at zero traffic.

The lifecycle of a function invocation.

Event arrives
Warm instance?
Cold start
Execute handler
Respond
Recycle
Reference

Key commands

curl -s -X POST -H 'Content-Type: application/json' -d '{"key":"value"}' https://api.example.com/handler

Trigger a serverless HTTP function with a JSON payload.

env

Inspect the runtime environment and injected configuration inside a function.

date -u

Record UTC timestamps in logs — function logs are aggregated across instances.

ps

See what processes the function sandbox actually runs.

free -m

Observe the memory available to the function's execution environment.

Hands-on

Examples

Measure warm versus cold invocation latency

Measure warm versus cold invocation latency
$ curl -s -o /dev/null -w "cold-ish: %{time_total}s\n" -X POST https://example.com/api/thumbnail
cold-ish: 0.82s
 
$ curl -s -o /dev/null -w "warm: %{time_total}s\n" -X POST https://example.com/api/thumbnail
warm: 0.09s

The first request pays the cold start: the platform must create a sandbox, load the runtime and import dependencies before the handler runs — often 0.3–1.5s. The warm request reuses an idle instance and finishes in tens of milliseconds. This gap is why latency-sensitive or always-active services may be better on containers.

Real world

In production

  • API backends that scale with traffic and drop to zero overnight save significant spend over always-on servers.
  • Event processors (image resizing on upload, log enrichment, webhook fan-out) map directly to triggers.
  • Scheduled jobs like daily exports or cleanup tasks replace cron on a server with scale-to-zero functions.
  • Fan-out patterns combine a function, a queue and a database to process thousands of messages concurrently.
Guidelines

Best practices

  • Keep functions small, single-purpose and under a hard timeout — long-running work belongs on a worker.
  • Set the memory size deliberately: more memory also buys proportional CPU, which can cut duration and total cost.
  • Design idempotent handlers because the platform may retry on failure or on redelivery.
  • Keep cold starts low by trimming the bundle, and use provisioned concurrency for latency-critical paths.
Watch out

Common mistakes

  • Assuming 'serverless' means no servers to think about — concurrency limits and timeouts are still yours to design for.
  • Putting heavy initialization (DB connections, SDK clients) inside the handler instead of the global init phase.
  • Using one giant function for many concerns, wrecking cold starts and testing.
  • Ignoring the execution time limit and hitting timeout in production.
Root cause analysis

Common issues

Error
Function timed out after 30 seconds
Root cause

The handler exceeds the configured execution timeout.

Fix

Raise the timeout deliberately, move slow work to queues or workers, or break the function into smaller steps.

Error
TooManyRequestsException / HTTP 429
Root cause

Concurrency or invoke rate limit reached for the account or function.

Fix

Increase reserved concurrency, add a queue in front to smooth the burst, or request a quota increase.

Error
Cold start latency spikes at peak
Root cause

Idle instances recycled, so a traffic spike pays many cold starts at once.

Fix

Enable provisioned concurrency for latency-critical functions, or move them to containers.

When things break

Debugging tips

  • Time every request and compare cold to warm latencies to isolate cold-start overhead from slow code.
  • Log at function start and end with UTC timestamps to spot dropped or retried invocations.
  • Watch concurrency and throttling metrics — 429s usually mean you hit the account concurrency limit.
  • Reproduce the event payload locally: most bugs come from assumptions about trigger data shape.
Interviews

Interview checkpoint

Practice

Hands-on lab

Simulate Event-Driven Invocations
25 min · intermediate
In progress
Objectives
  • Model a function handler that processes event records
  • Generate a stream of events and process them
  • Aggregate events the way a real handler would
  • Observe the resource footprint of the execution environment

Simulate Event-Driven Invocations

25 min · intermediate

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

Quick quiz

0/3
1

What is a cold start?

2

Which of these is a benefit of Functions-as-a-Service?

3

Serverless functions scale automatically based on the incoming request or event rate.

Quick reference

Cheat sheet

How FaaS works
TriggerHTTP, queue, bucket event, cron
Cold startFirst call pays provisioning latency
ScalePlatform-managed concurrency, scale-to-zero
BillingPer request + per compute-second (1ms)
LimitsTimeout and memory cap per function
Operating from the shell
curl -X POST -d '{"k":"v"}' <fn-url>Trigger an HTTP function
date -uUTC timestamps for log correlation
free -mMemory available in the sandbox
psProcesses running inside the environment
Go deeper

Official documentation

AWS Lambda: Getting Started
docs
Azure Functions: Overview
docs
Google Cloud Functions: Concepts
docs