⌘ The Architecture Reference

Cld serverless · Guide · Start here

What Is Serverless?

Serverless is not just FaaS — it is an ecosystem of fully managed services you compose rather than program, billed per use and scaled to zero.

Cld serverless Start here ⏱ 4 min read Complete

🧭 Analogy

Owning a car means buying it, insuring it, fuelling it, and parking it whether you drive or not. Serverless is ride-hailing: you summon a ride, pay only for the trip, and someone else owns, maintains, and parks the fleet. You stop managing the vehicle and start focusing on where you want to go.

Serverless is an ecosystem, not a technology

The single biggest misconception is that serverless equals FaaS equals AWS Lambda. Brisals and Hedger argue the opposite: serverless is a complete technology ecosystem of fully managed services, architectural patterns, organizational practices, and cultural habits. FaaS (function as a service) — running function code without provisioning hardware — is only one part of it.

The defining idea is undifferentiated heavy lifting: the patching, scaling, capacity planning, and high-availability work that gives your business no competitive advantage. You let the provider do it and you compose solutions from managed services rather than programming everything yourself. Two of the book’s maxims capture the mindset: “code is a liability; the system is the asset,” and “the code you write today is legacy tomorrow.”

Managed vs. fully managed

Not every cloud service is serverless. The book draws a sharp line:

  • Managed services still leave operational work to you. Amazon RDS, for example, runs the database engine but still requires you to set up a VPC, security groups, and instances.
  • Fully managed / serverless services abstract all of that away — Amazon DynamoDB and S3 have no servers to size or patch.
graph TD
C["Cloud services"] --> MS["Managed<br/>(you still operate)"]
C --> FM["Fully managed / serverless<br/>(nothing to size or patch)"]
MS --> RDS["Amazon RDS<br/>(VPC, security groups, instances)"]
FM --> DDB["DynamoDB"]
FM --> S3["S3"]
graph TD
E["Event source<br/>(API, queue, schedule, S3 upload)"] --> B["Event bus / trigger"]
B --> F["Function (FaaS)<br/>transform, not transport"]
F --> D["Fully managed data<br/>(DynamoDB, S3)"]
F --> O["Other managed services<br/>(SQS, EventBridge, Step Functions)"]
D --> X["Pay only for what you store/read"]
F --> Y["Pay only per invocation + memory"]

The serverless characteristics

  • Pay-per-use — you pay per invocation plus memory, and for data you pay per volume stored per month. No paying for a whole idle disk or array.
  • Autoscaling and scale to zero — services scale up and down automatically; idle environments are reclaimed. “Infinite” scaling is really bounded by account concurrency limits; provisioned concurrency keeps environments warm.
  • High availability out of the box — redundancy across Availability Zones avoids single points of failure.
  • Granular, per-resource control — configure each Lambda, SQS queue, or DynamoDB table independently (memory, timeout, concurrency, retention).

Cold starts and timeouts

A function’s first invocation pays a cold start — the latency to provision a fresh execution environment (an isolated Firecracker MicroVM). It is shaped by package size, language runtime, allocated memory, and static initialization. Functions also have a hard 15-minute maximum timeout, which rules out long-running jobs that cannot be split into chunks.

When serverless is the wrong fit

Serverless is “not a silver bullet.” Poor-fit workloads include compute-heavy/HPC tasks (use HPC-optimized instances), long-running batch beyond the function timeout, low-level OS/processor/network programs, ultra-fast consistent-response needs (~10ms, ~100% of the time), and durable connections over proprietary protocols. For these, consider a hybrid container-plus-serverless design — see serverless-first design, which frames serverless as a first choice, not a must.

Key insight

Adopting serverless successfully is as much about people, process, and culture as technology. The goal is to let the provider do the undifferentiated heavy lifting so your teams deliver business value faster — operating at a granular, per-resource level.

See also

When to use it — and when not

✅ Reach for it when

  • You want to outsource undifferentiated heavy lifting (patching, scaling, HA) to the cloud provider
  • Workloads are spiky or unpredictable and benefit from scale-to-zero and pay-per-use
  • You can compose a solution from managed services instead of running your own infrastructure

⛔ Think twice when

  • Compute-heavy/HPC or low-level OS/network programs that need dedicated hardware
  • Long-running batch jobs that exceed the 15-minute function timeout and cannot be split
  • Ultra-fast, consistent sub-10ms responses ~100% of the time, or durable proprietary-protocol connections
cld-serverlessServerless-First Design

Serverless-first means choosing serverless as the best-fit first option — reached through a sequence of X-first disciplines, not as a dogmatic must.

cld-serverlessEvent-Driven Serverless Patterns

Compose serverless systems from named patterns — storage-first, functionless integration, gatekeeper bus, choreography vs. orchestration — over an event-driven backbone.

Check your understanding

Score: 0 / 3

1. What is the most accurate definition of serverless?

Servers still exist — the provider runs them. Serverless means you stop managing infrastructure and compose managed services; FaaS is only one part of that ecosystem.

2. What does 'scale to zero' mean?

Managed services reclaim warm environments after inactivity, so you pay only for use. 'Infinite' scaling is bounded by account concurrency limits.

3. Which is a key serverless trade-off (gotcha)?

A new execution environment must be provisioned on first invocation; cold-start latency depends on package size, runtime, memory, and init work.

Comments

Sign in with GitHub to join the discussion.