Cloud Functions vs Backend Tradizionale: Quando il Serverless Ha Senso

Ogni nuovo progetto che inizio mi pone di fronte alla stessa decisione: avviare un server tradizionale o scrivere funzioni cloud? Dopo aver implementato sistemi in produzione su entrambi i fronti — Firebase Functions per workflow basati su eventi, AWS Lambda per endpoint API ed Express/Fastify per tutto il resto — ho un'opinione piuttosto sfumata su quando ciascun approccio sia effettivamente vincente. La risposta, prevedibilmente, è "dipende", ma vale la pena esplorare in dettaglio le specificità da cui dipende.

Definire i Due Approcci

Prima di confrontare, vorrei essere preciso su cosa intendo per ciascuno.

Un backend tradizionale si riferisce a un processo server a lunga esecuzione — un'applicazione Node.js Express, un server Python FastAPI, un server Go HTTP — distribuito su una VM, un container o una piattaforma di calcolo gestita. Il processo si avvia, rimane in esecuzione e gestisce le richieste man mano che arrivano. Gli obiettivi di deployment includono EC2, Cloud Run, ECS, Railway, Fly.io o un VPS nudo.

Le funzioni cloud (funzioni serverless) sono singoli gestori di funzioni che vengono eseguiti in risposta a eventi. La piattaforma gestisce interamente l'infrastruttura di calcolo. Il tuo codice viene eseguito, restituisce una risposta e l'ambiente di esecuzione può persistere o meno per l'invocazione successiva. I provider includono AWS Lambda, Google Cloud Functions, Firebase Functions, Azure Functions e Cloudflare Workers.

La distinzione non riguarda il linguaggio o il framework, ma il modello di esecuzione. Un backend tradizionale gestisce il ciclo di vita del proprio processo. Una funzione cloud no.

La Realtà dei Cold Start

I cold start sono la limitazione serverless più discussa, e la realtà nel 2026 è più sfumata di quanto suggerisca il dibattito.

Cosa Succede Realmente Durante un Cold Start

Quando una funzione cloud non è stata invocata di recente (o quando le invocazioni concorrenti superano le istanze "calde" disponibili), la piattaforma deve:

1. Provisionare un nuovo ambiente di esecuzione (microVM o container)
2. Scaricare edastrarre il tuo pacchetto di deployment
3. Inizializzare il runtime (Node.js, Python, ecc.)
4. Eseguire il tuo codice di inizializzazione (importazioni di moduli, configurazione SDK, connessioni DB)
5. Eseguire il gestore della funzione vera e propria

I passaggi 1-3 sono overhead della piattaforma. Il passaggio 4 è dove le tue scelte di codice contano enormemente.

Numeri dei Cold Start in Pratica

Ecco i tempi di cold start che ho misurato su diverse piattaforme e configurazioni in progetti reali:

Platform	Runtime	Bundle Size	Cold Start
AWS Lambda	Node.js 20	5 MB	250-400ms
AWS Lambda	Node.js 20	50 MB	800-1200ms
AWS Lambda	Python 3.12	10 MB	400-600ms
Firebase Functions v2	Node.js 20	15 MB	600-1000ms
Cloudflare Workers	JavaScript	1 MB	0-5ms
Google Cloud Functions v2	Node.js 20	10 MB	300-500ms

Cloudflare Workers sono un'eccezione perché utilizzano isolati V8 invece di container, il che elimina completamente la penalità di avvio del container. Il compromesso è un ambiente di runtime più vincolato.

Mitigare i Cold Start

Esistono diverse strategie che aiutano concretamente:

Provisioned concurrency (Lambda): Mantiene N istanze "calde" in ogni momento. Costa $0.0000041667 per GB-secondo di capacità provisionata. Per una funzione da 256MB, si tratta di circa $3.20/mese per istanza "calda". Ne vale la pena per endpoint sensibili alla latenza.

Minimum instances (Cloud Run, Firebase Functions v2): Stesso concetto, nome diverso. Cloud Run addebita le istanze inattive a una tariffa ridotta.

Riduzione della dimensione del bundle: Questo ha il rapporto impatto-sforzo più alto. Tree-shaking, esclusione delle dipendenze di sviluppo e l'uso di client SDK più leggeri riducono drasticamente il tempo di inizializzazione.

// Bad: imports the entire AWS SDK (adds 40MB+ to bundle)
import AWS from 'aws-sdk';

// Good: imports only the S3 client (adds ~3MB)
import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3';

Inizializzazione pigra (Lazy initialization): Non stabilire connessioni al database o caricare risorse pesanti a livello di modulo. Inizializzale alla prima invocazione e riutilizzale tra le invocazioni "calde".

import { Pool } from 'pg';

let pool: Pool | null = null;

function getPool(): Pool {
  if (!pool) {
    pool = new Pool({
      connectionString: process.env.DATABASE_URL,
      max: 1, // Single connection per Lambda instance
    });
  }
  return pool;
}

export async function handler(event: APIGatewayEvent) {
  const db = getPool();
  const result = await db.query('SELECT * FROM users WHERE id = $1', [event.pathParameters?.id]);
  return { statusCode: 200, body: JSON.stringify(result.rows[0]) };
}

Confronto dei Costi a Diverse Scale

Il costo è dove la conversazione si fa interessante, perché l'economia si inverte man mano che il traffico scala.

Traffico Basso (1.000 - 50.000 richieste/giorno)

A questa scala, il serverless è quasi sempre più economico. Molte startup e progetti secondari rientrano qui.

Costo Lambda per 30.000 richieste/giorno, durata media 200ms, 256MB di memoria:

• Costi di richiesta: 900K richieste/mese x $0.20/milione = $0.18
• Costi di calcolo: 900K x 0.2s x 0.25GB x $0.0000166667 = $0.75
• Totale: ~$1/mese

Server tradizionale equivalente (t4g.small su AWS):

• On-demand: $12.26/mese
• Con Piano di Risparmio di 1 anno: ~$8/mese

Con traffico basso, stai pagando per un server sempre attivo che è inattivo al 95%.

Traffico Medio (100.000 - 1.000.000 richieste/giorno)

Questa è la zona di crossover dove il confronto si fa più serrato.

Costo Lambda per 500.000 richieste/giorno, media 200ms, 256MB:

• Costi di richiesta: 15M/mese x $0.20/milione = $3.00
• Costi di calcolo: 15M x 0.2s x 0.25GB x $0.0000166667 = $12.50
• Totale: ~$15.50/mese

t4g.medium (2 vCPU, 4GB RAM):

• On-demand: $24.53/mese
• Con Piano di Risparmio: ~$16/mese

I costi sono paragonabili, ma il server tradizionale gestisce questo traffico con un significativo margine di manovra. Se il tuo traffico è costante, il server è leggermente più economico. Se il tuo traffico è a picchi (intenso nei giorni feriali, burst basati su eventi), la fatturazione per invocazione di Lambda significa che non paghi per i periodi di inattività.

Traffico Elevato (5.000.000+ richieste/giorno)

A questa scala, il serverless è quasi sempre più costoso per carichi di lavoro sostenuti.

Costo Lambda per 5.000.000 richieste/giorno, media 200ms, 512MB:

• Costi di richiesta: 150M/mese x $0.20/milione = $30
• Costi di calcolo: 150M x 0.2s x 0.5GB x $0.0000166667 = $250
• Totale: ~$280/mese

c6g.large (2 vCPU, 4GB RAM) con gruppo di auto-scaling:

• 2 istanze con Piano di Risparmio: ~$60/mese
• Con load balancer: ~$16/mese
• Totale: ~$76/mese

L'approccio tradizionale è 3,7 volte più economico a questa scala, e il divario si allarga all'aumentare del traffico.

Costi Nascosti da Considerare

La fatturazione di Lambda non è l'intero quadro. Aggiungi API Gateway ($1-3.50 per milione di richieste), CloudWatch Logs ($0.50/GB ingerito) e X-Ray tracing se lo usi. Dal lato tradizionale, aggiungi i costi del load balancer, del monitoraggio e il tempo operativo per la gestione delle istanze e dei deployment.

Differenze nell'Esperienza dello Sviluppatore

DX Serverless

Vantaggi:

• Nessuna infrastruttura da gestire (nessuna patch, nessuna configurazione di scaling)
• Il deployment per funzione significa un raggio d'azione più piccolo
• Sviluppo locale con emulatori (Firebase Emulator Suite, SAM CLI, Serverless Framework offline)
• Osservabilità integrata tramite il logging e il tracing della piattaforma

Punti dolenti:

• Lo sviluppo locale non corrisponde mai perfettamente al comportamento di produzione
• Il debug delle chiamate distribuite da funzione a funzione è più difficile che eseguire il debug di un monolite
• I limiti di dimensione del deployment (Lambda: 250MB decompressi) vincolano le scelte delle dipendenze
• La configurazione di IAM e dei permessi è verbosa e facile da sbagliare
• I cold start rallentano i cicli di iterazione dello sviluppo quando si testa contro funzioni già deployate

DX Backend Tradizionale

Vantaggi:

• L'ambiente di sviluppo locale è l'ambiente di produzione (stesso processo, stesso stato)
• Il debug è semplice — collega un debugger, imposta breakpoint, esegui passo passo
• Nessun limite di dimensione del deployment
• I pattern middleware, gli hook del ciclo di vita delle richieste e la gestione globale degli errori sono naturali
• Il supporto WebSocket, i processi a lunga esecuzione e i job in background funzionano senza servizi aggiuntivi

Punti dolenti:

• Sei responsabile del ciclo di vita dell'infrastruttura (aggiornamenti, scaling, controlli di salute)
• I deployment richiedono orchestrazione (aggiornamenti rolling, periodi di grazia per i controlli di salute)
• Lo scaling richiede configurazione (gruppi di auto-scaling, orchestrazione di container)
• Il monitoraggio e il logging richiedono una configurazione esplicita

Il Divario tra i Framework si Sta Riducendo

Framework come SST (Serverless Stack) e Architect hanno migliorato drasticamente la DX serverless. SST in particolare fornisce una modalità di sviluppo "Live Lambda" in cui il tuo codice in esecuzione localmente gestisce le invocazioni Lambda in tempo reale, eliminando completamente il ciclo deploy-test.

Dal lato tradizionale, piattaforme come Railway, Fly.io e Render hanno semplificato il deployment a git push. L'onere operativo di gestire un backend tradizionale è diminuito significativamente.

Quando il Serverless Vince

Carichi di Lavoro Basati su Eventi

Se il tuo codice viene eseguito in risposta a eventi — caricamenti di file, modifiche al database, messaggi di coda, attività pianificate — il serverless è la soluzione naturale. Non stai mantenendo un ciclo di polling o un processo listener. La piattaforma attiva il tuo codice esattamente quando necessario.

// Firebase Functions: triggered on Firestore document creation
import { onDocumentCreated } from 'firebase-functions/v2/firestore';

export const onOrderCreated = onDocumentCreated('orders/{orderId}', async (event) => {
  const order = event.data?.data();
  if (!order) return;

  // Send confirmation email
  await sendEmail(order.customerEmail, {
    template: 'order-confirmation',
    data: { orderId: event.params.orderId, items: order.items },
  });

  // Update inventory
  await updateInventory(order.items);

  // Notify restaurant
  await sendPushNotification(order.restaurantId, {
    title: 'New Order',
    body: `Order #${event.params.orderId} received`,
  });
});

Traffico Sporadico o Imprevedibile

Uno strumento interno che riceve 50 richieste il lunedì mattina e 2 richieste il resto della settimana. Un ricevitore di webhook che elabora eventi da un'API di terze parti. Un generatore di report pianificato che viene eseguito per 30 secondi una volta al giorno. Questi carichi di lavoro hanno un costo quasi nullo sul serverless e sprecano denaro su infrastrutture sempre attive.

Endpoint API con Traffico Basso-Medio

Per un'API MVP di una startup che serve qualche migliaio di richieste al giorno, il serverless fornisce un backend funzionale con un overhead operativo minimo e un costo quasi nullo. Puoi concentrarti interamente sulla logica di business.

Elaborazione Dati Parallela

Hai bisogno di elaborare 10.000 immagini, transcodificare 500 video o eseguire analisi su un grande dataset? Distribuisci a migliaia di invocazioni Lambda concorrenti, elabora in parallelo e paga solo per il tempo di calcolo utilizzato. Ottenere lo stesso parallelismo con server tradizionali richiede il provisioning (e il pagamento) di quella capacità di picco.

Quando i Backend Tradizionali Vincono

Connessioni Persistenti

Le connessioni WebSocket, i Server-Sent Events, gli stream gRPC e il long-polling richiedono tutti una connessione persistente tra client e server. Le funzioni Lambda hanno un limite di esecuzione di 15 minuti e non sono progettate per connessioni a lunga durata.

Puoi aggirare questo problema con le API WebSocket di API Gateway o AWS IoT Core, ma la complessità e il costo spesso superano un semplice server WebSocket su Cloud Run o una piattaforma container.

Pipeline di Richieste Complesse

Quando una richiesta passa attraverso autenticazione, rate limiting, validazione dell'input, logica di business, operazioni di database, aggiornamenti della cache, emissione di eventi e formattazione della risposta — il pattern della pipeline middleware di Express/Fastify/Koa è ergonomicamente superiore al pattern flat handler delle funzioni cloud.

// Traditional: clean middleware pipeline
app.use(cors());
app.use(helmet());
app.use(rateLimiter);
app.use(authenticate);
app.use('/api/v1', apiRouter);
app.use(errorHandler);

Replicare questo in Lambda richiede un framework come Middy (che aggiunge peso e complessità) o la duplicazione del codice di setup tra le funzioni.

Operazioni Stateful

Se la tua applicazione mantiene uno stato in memoria — una cache, un pool di connessioni, un contatore di rate limiter, dati di sessione — un server tradizionale gestisce questo naturalmente. Le funzioni Lambda possono riutilizzare lo stato tra invocazioni "calde", ma non puoi farci affidamento. Qualsiasi stato che deve persistere necessita di un servizio esterno (Redis, DynamoDB), il che aggiunge latenza e costo.

Requisiti di Latenza Stretti

Per le API dove ogni millisecondo conta — offerte in tempo reale, server di gioco, transazioni finanziarie — la latenza imprevedibile introdotta dai cold start è inaccettabile, anche con la concurrency provisionata. Un processo server ben ottimizzato con connection pooling e cache "calde" offre tempi di risposta consistenti inferiori a 10ms che il serverless non può garantire.

L'Approccio Ibrido

In pratica, la maggior parte dei sistemi di produzione che costruisco finisce per essere ibrida. L'API principale gira su un backend tradizionale (Cloud Run o una piattaforma container), mentre i carichi di lavoro ancillari girano su funzioni cloud.

Un'Architettura Ibrida Pratica

Client
  │
  ├─→ API Gateway / Load Balancer
  │     └─→ Cloud Run (main API)
  │           ├─→ PostgreSQL (Cloud SQL)
  │           ├─→ Redis (Memorystore)
  │           └─→ Pub/Sub (event bus)
  │
  └─→ Cloud Functions (event handlers)
        ├─→ Image processing (on upload)
        ├─→ Email sending (on order creation)
        ├─→ Analytics aggregation (scheduled)
        └─→ Webhook processing (HTTP trigger)

L'API principale gestisce il traffico sincrono richiesta-risposta con connessioni persistenti al database, caching in memoria e latenza consistente. Le funzioni cloud gestiscono carichi di lavoro asincroni e basati su eventi dove i cold start non contano perché l'utente non sta aspettando una risposta.

Strategia di Migrazione: da Tradizionale a Serverless

Se hai un backend tradizionale esistente e vuoi adottare il serverless selettivamente:

1. Identifica le operazioni basate su eventi attualmente in esecuzione come job in background, attività cron o consumer di code. Queste sono le più facili da migrare.
2. Estrai endpoint indipendenti che non condividono lo stato con altri endpoint. Gli endpoint di controllo dello stato (health check), i ricevitori di webhook e le API di utilità sono buoni candidati.
3. Mantieni l'API principale tradizionale a meno che tu non abbia una ragione convincente per decomporla. L'overhead operativo di gestire 50 funzioni Lambda spesso supera la gestione di un singolo container.
4. Usa un event bus (Pub/Sub, EventBridge, SQS) come livello di integrazione tra la tua API tradizionale e le funzioni serverless. L'API pubblica eventi; le funzioni si iscrivono e reagiscono.

Strategia di Migrazione: da Serverless a Tradizionale

Andare nella direzione opposta è talvolta necessario quando un'API serverless supera la sua architettura:

1. Non riscrivere tutto in una volta. Inizia consolidando le funzioni con il traffico più elevato in un unico server API.
2. Mantieni le funzioni basate su eventi come funzioni. Migra solo i gestori richiesta-risposta.
3. Usa le stesse route API. Punta il tuo API Gateway/load balancer al nuovo server per le route migrate e continua a instradare a Lambda per il resto.
4. Migra prima le connessioni al database. Il maggiore guadagno in termini di prestazioni si ottiene passando dalla configurazione della connessione per invocazione al connection pooling persistente.

Note Specifiche della Piattaforma

Firebase Functions (v2)

Firebase Functions v2 gira su Cloud Run, il che gli conferisce vantaggi significativi rispetto alla v1: concurrency configurabile (più richieste per istanza), istanze minime, timeout più lunghi (fino a 60 minuti) e allocazioni di memoria maggiori. Se utilizzi le funzioni Firebase v1, l'aggiornamento alla v2 vale lo sforzo di migrazione.

La Firebase Emulator Suite offre la migliore esperienza di sviluppo locale nello spazio serverless. Emula Firestore, Auth, Storage e Functions in un unico ambiente locale, con hot-reload sulle modifiche al codice.

AWS Lambda

Lambda ha l'ecosistema di integrazione più profondo — trigger da praticamente ogni servizio AWS, layer per codice condiviso e SnapStart per carichi di lavoro Java. La funzionalità URL della funzione elimina la necessità di API Gateway per casi d'uso semplici, risparmiando $3.50 per milione di richieste.

Lambda@Edge e CloudFront Functions sono potenti per la manipolazione di richieste/risposte a livello CDN, ma l'esperienza di sviluppo e debug è significativamente peggiore rispetto a Lambda standard.

Cloud Run

Cloud Run sfuma il confine tra serverless e tradizionale. Esegue container (qualsiasi linguaggio, qualsiasi framework), scala a zero e supporta la concurrency (più richieste per istanza). È serverless nel modello di fatturazione ma tradizionale nel modello di esecuzione. Per i team che desiderano l'economia serverless senza riscrivere il proprio codice come gestori di funzioni, Cloud Run è spesso la risposta giusta.

Prendere la Decisione

Ecco il framework decisionale che utilizzo:

1. Il carico di lavoro è basato su eventi e asincrono? Serverless.
2. Il traffico è basso e imprevedibile? Serverless.
3. Hai bisogno di connessioni persistenti o di stato in memoria? Tradizionale.
4. La bassa latenza consistente è critica? Tradizionale.
5. Il team è piccolo e avverso alle operazioni? Serverless (o Cloud Run).
6. Il traffico è elevato e costante? Tradizionale (più economico).
7. È un mix di quanto sopra? Ibrido.

La decisione peggiore è trattare questa scelta come un tutto o niente. Usa lo strumento giusto per ogni carico di lavoro, collegali tramite interfacce ben definite e otterrai i benefici di entrambi senza impegnarti completamente in uno solo.