Serverless Computing: What You Gain and What You Give Up

Learning Material · Cloud Computing

"Serverless" doesn't mean no servers

Servers still run your code — you just never provision, patch, or manage them directly. You write a function, the cloud provider (AWS Lambda, Google Cloud Functions, Azure Functions) runs it on demand, and you're billed only for the actual compute time your function used, down to fractions of a second.

A minimal serverless function

exports.handler = async (event) => {
  const name = event.queryStringParameters?.name || 'World'
  return {
    statusCode: 200,
    body: JSON.stringify({ message: `Hello, ${name}` })
  }
}

There's no server process to start, no port to listen on — the platform invokes this function directly whenever a matching HTTP request (or queue message, or scheduled trigger) arrives, and shuts it down when idle.

What you gain

• No servers to patch, scale manually, or keep running 24/7
• Automatic scaling — from zero requests to thousands, with no configuration
• Pay only for actual usage, not for idle server capacity sitting unused

Cold starts: the tradeoff nobody advertises upfront

When a function hasn't run recently, the platform needs to initialize a fresh execution environment before running your code — this "cold start" can add anywhere from tens of milliseconds to a few seconds of latency, depending on the runtime and how much needs to initialize. For a user-facing API where latency matters on every request, this is a real, measurable cost that a traditional always-running server doesn't have.

Statelessness is mandatory, not optional

A serverless function cannot reliably keep anything in memory between invocations — the platform may run a fresh instance for the next request, or run several in parallel. Anything that needs to persist (sessions, counters, cached data) has to live in an external store (a database, Redis), which is a real architectural constraint, not a minor inconvenience.

Where serverless fits best

Bursty or unpredictable traffic (an endpoint hit occasionally, or a scheduled batch job) is close to the ideal use case — you pay almost nothing when idle, and scale instantly when traffic spikes. A consistently high-traffic API, by contrast, often ends up cheaper and more predictable on traditional always-on servers, where cold starts also aren't a concern at all.