☁️ Serverless Computing Principles

What Is Serverless, Really?

Serverless computing is a cloud execution model where the provider dynamically allocates, runs, and tears down the compute your code needs — on demand, per request. Your code runs in short-lived, stateless containers that are created when an event arrives and disposed of soon after. You never provision a machine, patch an OS, or configure a load balancer; you upload code and describe what should trigger it.

💡 Analogy — owning a car vs. calling a rideshare. A traditional server is a car you lease: you pay for it around the clock, you handle insurance and maintenance, and you must guess how big a vehicle to buy before you know the demand. Serverless is a rideshare: you pay only for the trips you actually take, someone else maintains the fleet, and a bigger vehicle — or ten more of them — shows up automatically when you need capacity. When you're not travelling, you pay nothing.

That single shift — from "capacity you rent" to "work you consume" — is what drives every other property of serverless. Keep it in mind as we go.

Two Flavours: FaaS and BaaS

"Serverless" is an umbrella over two related but distinct ideas.

Function as a Service (FaaS)

You write small, single-purpose functions and hand them to the platform. The platform runs a function when its trigger fires — an HTTP request, a file upload, a queue message, a schedule — and scales the number of concurrent copies to match the load. This is the part people usually mean when they say "serverless."

// A minimal AWS Lambda handler (Node.js)
export const handler = async (event) => {
  const name = event.queryStringParameters?.name ?? 'World';
  return {
    statusCode: 200,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      message: `Hello, ${name}!`,
      timestamp: new Date().toISOString(),
    }),
  };
};

Backend as a Service (BaaS)

Instead of writing the backend feature yourself, you consume a fully-managed one through an SDK or API: authentication, a realtime database, file storage, push notifications. Firebase, Supabase, Auth0, and AWS Cognito are classic examples. You still write frontend and glue code, but whole categories of backend work simply vanish.

Real applications freely mix the two: a Lambda function (FaaS) that verifies a token issued by Cognito (BaaS) and writes to DynamoDB (BaaS).

The Five Core Principles

1 · No server management

You are abstracted entirely away from provisioning, patching, and scaling machines. This is the top of a long evolution — each step handed more responsibility to the provider:

2 · Pay-per-execution

Billing is metered on actual invocations, execution time, and memory — not on reserved capacity. When nothing is happening, you pay nothing (this is called scaling to zero). For spiky or low-volume workloads the savings are dramatic:

*Rough illustrative figures for an API serving ~1M requests/month; your mileage will vary by provider and workload.

3 · Automatic scaling

The platform runs as many concurrent copies of your function as demand requires, from zero to thousands, with no configuration. A traffic spike simply causes more instances to spin up; the surge subsides and they disappear. There is no capacity to plan and no idle fleet to pay for during the quiet hours.

4 · Event-driven execution

Functions don't run in a loop waiting for work — they are triggered by events. This is the beating heart of the model.

5 · Statelessness

Each invocation may land on a brand-new container with no memory of previous runs. Any state you need must live in an external service. We'll dig into what that means for your code next.

Statelessness in Practice

Because the execution environment is ephemeral, you cannot rely on in-memory variables or the local filesystem to survive between requests. Instead, push state into a database, cache, or object store. Here is the pattern — notice that the client is created once outside the handler (so a re-used "warm" container can share it) while the actual state lives in Redis:

import { createClient } from 'redis';

// Created once per container and reused across warm invocations.
// This is NOT durable state — it is a connection we happen to keep alive.
const redis = createClient({ url: process.env.REDIS_URL });
let connected = false;

export const handler = async (event) => {
  if (!connected) {
    await redis.connect();
    connected = true;
  }

  const sessionId = event.headers['x-session-id'];
  const key = `session:${sessionId}`;

  // Durable state lives in Redis, not in the function
  const raw = await redis.get(key);
  const session = raw ? JSON.parse(raw) : { visits: 0 };

  session.visits += 1;
  session.lastVisit = new Date().toISOString();

  await redis.set(key, JSON.stringify(session), { EX: 3600 });

  return {
    statusCode: 200,
    body: JSON.stringify({ visits: session.visits }),
  };
};

Trade-offs & Limitations

Serverless is powerful, not magic. Know the sharp edges before you commit.

Cold starts

When no warm container is available, the platform must create one — load the runtime, import dependencies, run initialisation — before your handler executes. That first-request latency is the cold start.

Execution-duration limits

FaaS platforms cap how long a single invocation may run, so they are unsuitable for long batch jobs. Split long work into steps or move it to a container/queue-worker instead.

State & testing complexity

Statelessness forces every bit of shared state into external services, and locally reproducing cloud triggers (an S3 upload event, a DynamoDB stream) is fiddly. Tools like the AWS SAM CLI, the Serverless Framework's offline plugin, and LocalStack help, but local behaviour never perfectly mirrors the cloud.

Vendor lock-in

Deep use of provider-specific services (DynamoDB, Cognito, EventBridge) makes switching clouds costly. Reduce the blast radius by keeping core business logic free of provider SDKs (hexagonal architecture) and hiding cloud services behind your own interfaces.

When to Reach for Serverless

Serverless excels at event-driven, bursty, and glue-code workloads:

Hands-on Exercise

Quiz

Summary & Next Steps

📚 Further Reading

• Martin Fowler — Serverless Architectures
• AWS Lambda Developer Guide
• Serverless Framework

🚀 What's Next?

Now that you understand the model, we'll go hands-on with the most widely used FaaS platform. In AWS Lambda Function Development you'll write, configure, secure, and deploy real functions.