Serverless Functions
debt(d9/e7/b7/t7)
Closest to 'silent in production until users hit it' (d9), no automated tool flags 'this app would suit Lambda' — detection_hints.automated is no, and misuse (state in memory, cold starts) only surfaces in production traffic patterns.
Closest to 'cross-cutting refactor across the codebase' (e7), migrating to Bref/Lambda requires reworking state handling, deployment, bootstrapping, and packaging across the whole app — not a single-file change.
Closest to 'strong gravitational pull' (b7), applies_to web+cli contexts and the serverless model shapes every handler: statelessness, cold starts, packaging size, and timeout limits constrain how new features are written.
Closest to 'serious trap' (t7), the misconception ('serverless means no servers') plus filesystem/memory state assumptions contradict how traditional PHP-FPM apps behave — devs reach for $_SESSION or local files and silently break.
Also Known As
TL;DR
Explanation
Serverless (Lambda, Cloud Functions, Azure Functions) runs code in response to events (HTTP request, queue message, cron schedule) without provisioning or managing servers. Billing is per invocation and execution time — idle costs nothing. Cold starts add latency when a function hasn't run recently. Functions must be stateless — any persistent state lives in a database or cache. PHP is supported via custom runtimes (Bref) on AWS Lambda.
Diagram
flowchart LR
REQ[HTTP Request] --> GW[API Gateway]
GW -->|cold start or warm| FN[Function Instance<br/>PHP via Bref]
FN --> EXEC[Execute handler<br/>100ms-3s]
FN --> DB[(Database)]
FN --> S3[(S3)]
subgraph Scaling
GW -->|concurrent requests| FN1[Instance 1]
GW -->|concurrent requests| FN2[Instance 2]
GW -->|concurrent requests| FN3[Instance N - auto]
end
INFO[Pay per invocation<br/>Zero idle cost<br/>Cold start: 200ms-2s]
style FN fill:#238636,color:#fff
style INFO fill:#1f6feb,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- Storing state in the function's memory or filesystem — functions are ephemeral; use Redis or a database.
- Ignoring cold start latency — functions not invoked recently take 200-2000ms to initialise.
- Monolithic serverless functions — small, single-purpose functions scale and deploy independently.
- Not setting memory/timeout limits — unlimited execution time runs up costs on stuck functions.
Code Examples
// Stateful serverless — state lost between invocations:
$counter = 0; // Top-level 'global' variable
function handler($event) {
global $counter;
$counter++; // Resets to 0 on every cold start — not persistent
return ['count' => $counter];
}
// Stateless — state in Redis:
function handler($event) {
$redis = new Redis();
$redis->connect(getenv('REDIS_HOST'));
$count = $redis->incr('invocation_count');
return ['count' => $count]; // Persists across invocations
}
// Bref (PHP on Lambda): composer require bref/bref