Il Problema dei Cold Starts nel Serverless Tradizionale

Nel 2024, un'analisi di Datadog ha documentato che il 40% delle invocazioni Lambda in produzione subisce cold starts superiori ai 500ms. Per funzioni Python o Java questo numero sale a 1-3 secondi. Il cold start è il tempo che passa dal momento in cui arriva una richiesta al momento in cui la funzione è effettivamente pronta ad elaborarla: è il tempo necessario per avviare un container, caricare il runtime, inizializzare le dipendenze.

Cloudflare Workers ha un approccio radicalmente diverso: invece di container, usa V8 Isolates. Il risultato misurabile: avvio medio inferiore a 1ms, zero "cold starts" nel senso tradizionale del termine. Capire perché richiede di scendere nel dettaglio dell'architettura del motore V8 e del modello di isolamento dei processi.

Container, Processi e Isolates: una Tassonomia

Per comprendere gli isolates bisogna prima capire cosa stanno sostituendo. Ogni livello dell'astrazione ha un costo di avvio differente:

Un V8 Isolate è un'istanza isolata della JavaScript heap di V8: ha il proprio heap allocator, i propri oggetti JavaScript, la propria garbage collector. Due isolates non condividono memoria JavaScript e non possono interferire l'uno con l'altro. Questo è il fondamento dell'isolamento di sicurezza di Workers, ma la conseguenza architettonica è che creare un isolate è un'operazione che richiede microsecondi, non millisecondi.

Perché Lambda Soffre di Cold Starts

Quando arriva una richiesta a una Lambda function "fredda" (non warm, senza un container pre-allocato), AWS deve eseguire questa sequenza:

# Sequenza di cold start Lambda (Node.js 20)
1. Allocazione risorse compute (EC2/Firecracker VM)      ~50-200ms
2. Download immagine container dal registro              ~50-300ms (dipende dalla dimensione)
3. Setup rete: VPC, ENI attachment (se VPC configurata) ~200-1000ms (!)
4. Avvio runtime Node.js                                 ~30-80ms
5. Caricamento dependencies (node_modules)               ~20-200ms
6. Esecuzione handler initialization code               ~10-500ms
7. Prima invocazione effettiva                           ----------

Totale cold start: 360ms - 2.28 secondi (VPC worst case: fino a 3-5s)

Firecracker (la microVM usata da AWS) ha ridotto il tempo di avvio della VM a circa 125ms, ma il problema strutturale rimane: ogni ambiente di esecuzione è un contenitore isolato a livello kernel che deve essere avviato da zero ad ogni cold start.

V8 Isolates: l'Architettura di Workers

Cloudflare Workers gira su workerd, il runtime open-source rilasciato da Cloudflare nel 2022. Ogni PoP (Point of Presence, sono 300+ in tutto il mondo) esegue una flotta di processi workerd. Quando arriva una richiesta:

Sequenza di gestione richiesta in Cloudflare Workers:

1. Richiesta arriva al PoP Cloudflare piu vicino        ~0ms (BGP anycast routing)
2. Routing al processo workerd appropriato               ~0.1ms
3. Lookup/allocation dell'isolate per questo Worker      ~0.5ms (da pool precreato)
4. Esecuzione del fetch handler                          ~0.1ms overhead
5. Risposta

Totale "startup": < 1ms

Il punto chiave è nel passaggio 3: workerd mantiene un pool di isolates pre-inizializzati. Ogni isolate ha già caricato il codice del Worker grazie agli V8 Snapshots.

V8 Snapshots: Serializzare lo Stato dell'Heap

V8 supporta la serializzazione dell'heap in un formato binario chiamato "snapshot". Quando fai il deploy di un Worker, Cloudflare:

1. Esegue il codice JavaScript del Worker in un isolate temporaneo
2. Lascia che il codice completi la sua inizializzazione (module evaluation)
3. Serializza l'heap dell'isolate in uno snapshot binario
4. Distribuisce questo snapshot ai PoP
5. I nuovi isolates vengono creati da questo snapshot (deserializzazione), non da zero

// Il tuo Worker ha questa struttura:
import { Router } from 'itty-router';

// Questo codice viene eseguito durante il "module evaluation"
// e serializzato nello snapshot
const router = new Router();

router.get('/users/:id', async ({ params, env }) => {
  const user = await env.DB.get(`user:${params.id}`);
  return Response.json({ user });
});

// Il fetch handler e il punto di ingresso per ogni richiesta
export default {
  fetch: router.fetch
};

// Quando un isolate viene creato dallo snapshot:
// - router e gia costruito e configurato
// - tutte le route sono gia registrate
// - NON c'e alcun costo di module evaluation per ogni richiesta

Questo è fondamentalmente diverso da ciò che accade in Lambda: in Lambda, ogni cold start deve re-eseguire tutto il codice di inizializzazione del modulo. In Workers, questa fase è avvenuta una volta sola al momento del deploy.

Isolamento di Sicurezza: V8 Sandbox

Un'obiezione comune è: "se più Workers girano nello stesso processo, come vengono isolati?". La risposta è il V8 Sandbox, un meccanismo multi-strato:

Il modello non è privo di rischi: vulnerabilità nel parser V8 potrebbero teoricamente permettere escape dall'isolate. Cloudflare ha un programma di bug bounty dedicato e aggiorna regolarmente V8. Per workload ad alta sicurezza, Cloudflare offre anche modalità di isolamento più stringenti.

Limiti del Modello Isolate

L'assenza di cold start ha un costo: il modello isolate impone vincoli che i container non hanno:

Il limite di CPU time è il più importante da capire: non è un timeout wall-clock. Workers misura il tempo di CPU effettivamente consumato. Un Worker può fare molte chiamate I/O asincrone (fetch, KV) che non consumano CPU time. Il limite si applica solo al codice JavaScript in esecuzione.

Benchmark: Workers vs Lambda vs Lambda@Edge

Ecco un confronto basato su benchmark pubblici e documentazione ufficiale (2025):

Un Worker Minimale: Capire il Modello di Esecuzione

Per rendere concreto quanto spiegato, ecco il codice più semplice possibile che mostra il ciclo di vita di un Worker:

// worker.ts - formato ES Module (obbligatorio con isolates moderni)

// FASE 1: Module evaluation (eseguita UNA VOLTA, serializzata nello snapshot)
console.log('Questo viene eseguito solo al deploy, non per ogni richiesta');

const CONFIG = {
  version: '1.0',
  region: 'auto',
};

// FASE 2: Export del handler - il punto di ingresso per ogni richiesta
export default {
  // Chiamato per ogni HTTP request
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    // request: la richiesta HTTP
    // env: i binding (KV, R2, D1, secrets, variables)
    // ctx: context per waitUntil() - operazioni post-risposta

    const url = new URL(request.url);
    const path = url.pathname;

    // ctx.waitUntil() permette operazioni asincrone dopo la risposta
    ctx.waitUntil(logRequest(request, env));

    if (path === '/health') {
      return new Response(JSON.stringify({
        status: 'ok',
        config: CONFIG,
        timestamp: Date.now(),
      }), {
        headers: { 'Content-Type': 'application/json' },
      });
    }

    return new Response('Not Found', { status: 404 });
  },
};

async function logRequest(request: Request, env: Env): Promise<void> {
  // Questo viene eseguito dopo che la risposta e gia stata inviata
  // Non blocca il client
  await env.ANALYTICS_KV.put(
    `log:${Date.now()}`,
    JSON.stringify({
      url: request.url,
      method: request.method,
      cf: request.cf, // Informazioni Cloudflare: paese, ASN, datacenter, etc.
    })
  );
}

// Interfaccia per i binding definiti in wrangler.toml
interface Env {
  ANALYTICS_KV: KVNamespace;
  API_KEY: string; // secret
}

Il Modello di Concorrenza: Un Isolate, Molte Richieste

Un aspetto sottile ma importante: a differenza di Lambda dove ogni invocazione ha il proprio ambiente isolato, in Workers lo stesso isolate può gestire più richieste concorrenti. Questo è possibile perché JavaScript è single-threaded con event loop, quindi non c'è vera concorrenza sullo stato condiviso, ma è possibile multiplexare richieste I/O-bound.

// ATTENZIONE: stato globale condiviso tra richieste
// In Lambda questo non sarebbe un problema (ogni invocazione ha il suo processo)
// In Workers, piu richieste possono condividere lo stesso isolate

// SBAGLIATO: questo contatore e condiviso tra tutte le richieste
let requestCount = 0;

export default {
  async fetch(request: Request): Promise<Response> {
    requestCount++; // Race condition! Non fare questo.
    return new Response(`Request #${requestCount}`);
  },
};

// CORRETTO: usa ctx.waitUntil() per operazioni post-risposta
// e storage esterno (KV) per contatori condivisi
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    const count = parseInt(await env.COUNTERS.get('requests') ?? '0') + 1;
    ctx.waitUntil(env.COUNTERS.put('requests', String(count)));
    return new Response(`Requests: ${count}`);
  },
};

Workerd: Il Runtime Open-Source

Nel settembre 2022, Cloudflare ha reso open-source workerd (github.com/cloudflare/workerd), il runtime che alimenta Workers. Questo ha avuto conseguenze importanti:

• Deno Deploy ha adottato V8 isolates con architettura simile
• Miniflare (il simulatore locale) usa workerd internamente da v3
• È possibile eseguire workerd on-premise per ambienti privati
• La community può contribuire al runtime e ispezionare il codice di sicurezza

# Architettura workerd (semplificata)

┌─────────────────────────────────────────────────┐
│                  workerd process                │
│                                                 │
│  ┌──────────────┐  ┌──────────────┐            │
│  │  Isolate #1  │  │  Isolate #2  │   ...      │
│  │  (Worker A)  │  │  (Worker B)  │            │
│  │              │  │              │            │
│  │  V8 Heap A   │  │  V8 Heap B   │            │
│  │  (isolato)   │  │  (isolato)   │            │
│  └──────┬───────┘  └──────┬───────┘            │
│         │                 │                    │
│  ┌──────▼─────────────────▼───────┐            │
│  │        I/O Subsystem           │            │
│  │  (fetch, KV, R2, D1, DO, AI)  │            │
│  └───────────────────────────────┘            │
│                                                 │
│  ┌─────────────────────────────────────────┐   │
│  │        Network Layer                    │   │
│  │  (Cloudflare anycast, TLS, HTTP/3)     │   │
│  └─────────────────────────────────────────┘   │
└─────────────────────────────────────────────────┘

Quando NON Usare Workers

I V8 isolates non sono la risposta a tutto. Ci sono scenari dove Lambda o container restano la scelta giusta:

• Computazione CPU-intensive lunga: Training ML, rendering video, encoding audio. Il limite di 30s di CPU time e 128MB di RAM è proibitivo.
• Codice non-JavaScript: Workers supporta WebAssembly ma non tutti i linguaggi compilano bene in WASM. Python, Java, Ruby nativi richiedono Lambda.
• Node.js ecosystem completo: Molte librerie npm usano API native Node.js (fs, crypto avanzato, buffer manip) non disponibili in Workers.
• State management complesso: Se hai bisogno di sessioni WebSocket durature con molto stato, considera i Durable Objects (vedi articolo 4 della serie).
• Database connessioni persistenti: Workers non mantiene connessioni TCP persistenti tra richieste. Usa Hyperdrive per pooling verso database tradizionali.

Conclusioni e Prossimi Passi

I V8 isolates rappresentano un cambio di paradigma architetturale, non solo un'ottimizzazione: spostano il confine di isolamento dal livello kernel al livello runtime, ottenendo tempi di avvio sub-millisecondo con sicurezza sufficiente per l'edge computing multi-tenant. Il costo è un ambiente d'esecuzione più vincolato rispetto ai container tradizionali.

Per la maggior parte delle API RESTful, middleware di autenticazione, trasformazione di richieste e personalizzazione dei contenuti, i vincoli di Workers sono più che accettabili, e il guadagno in latenza e globale e misurabile.