Nel modello di hosting tradizionale (EC2, DigitalOcean), noleggi un computer. Paghi € 50 al mese. Se nessuno visita il tuo sito alle 3:00, il computer rimane inattivo. Paghi ancora. Se 100.000 persone visitano la sala alle 10:00, il computer si blocca. Perdi entrate.

Questo è il dilemma della Pianificazione della capacità. Devi rigorosamente effettuare un provisioning eccessivo per gestire i picchi, il che significa che stai pagando troppo il 99% delle volte.

Serverless (FaaS) capovolge il modello. Non noleggi un computer. Carichi il codice. Paghi per invocazione.

0 visite = € 0,00.
1 milione di visite = AWS avvia 1.000 funzioni simultanee. Paghi esattamente per 1 milione di secondi di esecuzione.

Noi di Maison Code Paris utilizziamo Serverless non solo per i costi, ma per la semplicità operativa. Non applichiamo patch ai kernel Linux. Non ruotiamo le chiavi SSH. Ci concentriamo sulla Logica.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

Perché Maison Code adotta innanzitutto il serverless

Trattiamo le infrastrutture come una passività, non come una risorsa. Ogni server che gestiamo è un server che può rompersi. La nostra filosofia “Scale-to-Zero” è in linea con il profitto e la perdita dei nostri clienti:

Efficienza: abbiamo migrato i lavori cron legacy di un cliente da un EC2 dedicato da € 100/mese a Lambda. Il costo è sceso a € 0,12/mese.
Resilienza: durante il Black Friday, i nostri endpoint Serverless sono riusciti a raggiungere 5.000 esecuzioni simultanee senza un singolo timeout.
Focus: i nostri ingegneri dedicano il 100% del loro tempo alla logica aziendale (prezzi, carrello, pagamento), non all’orchestrazione Docker.

Architettura: modelli guidati dagli eventi

Il serverless è migliore quando è asincrono. Anche se puoi eseguire un’API standard (GET /users), la vera potenza sta nell’Event Sourcing.

Il modello buffer (SQS + Lambda)

Scenario: esegui una vendita flash. 10.000 utenti effettuano il checkout in 1 secondo. Se colleghi Lambda direttamente al tuo ERP (SAP/NetSuite), effettuerai un DDoS sul tuo ERP. Non può gestire connessioni da 10k.

Soluzione:

API Gateway: accetta la richiesta HTTP. Restituisce “202 Accettato”.
SQS (Simple Queue Service): archivia la richiesta in una coda. Può contenere milioni di messaggi.
Lambda: interroga la coda. Elabora i messaggi a una velocità controllata (ad esempio, 50 alla volta).
Risultato: il tuo ERP riceve un flusso costante di ordini, non uno tsunami. L’utente riceve una risposta rapida.

Gestione degli errori: la coda delle lettere non recapitate (DLQ)

In un server Node.js, se una richiesta si blocca, viene persa. In Serverless, configuriamo Retries. AWS Lambda ritenterà automaticamente una funzione asincrona non riuscita 2 volte. Se il problema persiste (ad esempio, bug nel codice), sposta l’evento in una Dead Letter Queue (DLQ). Gli ingegneri possono ispezionare il DLQ, correggere il bug e “Redrive” i messaggi. Nessun dato viene perso.

Il problema dell’avvio a freddo

Le risorse non sono gratuite. Per risparmiare denaro, AWS spegne il container se non viene utilizzato per circa 15 minuti. La richiesta successiva attiva un Cold Start.

AWS assegna una microVM (Petardo).
Scarica il tuo codice.
Avvia Node.js.
Esegue il tuo gestore.

Latenza: ~300ms - 1s (Node.js). ~3s (Java). Impatto: va bene per i lavori in background. Dannoso per le API di pagamento.

La soluzione: Vercel Edge Runtime (isolati V8)

Vercel (e Cloudflare Workers) hanno introdotto un nuovo runtime. Invece di avviare un contenitore Node.js completo (VM + sistema operativo + nodo), vengono eseguiti su V8 Isolates. Questo è lo stesso motore che esegue JavaScript in Chrome.

Avvio a freddo: ~0ms.
Limiti: non puoi utilizzare API Node.js come fs, child_process o file binari nativi.
Caso d’uso: middleware, reindirizzamento di autenticazione, bucket di test A/B, routing geografico.

La trappola del database: pooling delle connessioni

È qui che il 90% dei principianti fallisce. Una libreria Postgres standard (pg) apre una connessione TCP. In un server monolite, apri 1 connessione e la condividi. In Serverless ogni funzione è un contenitore isolato. Se hai 1.000 utenti simultanei, apri 1.000 connessioni DB. Postgres esaurisce la RAM e si blocca. “FATAL: gli slot di connessione rimanenti sono riservati”.

Soluzione 1: pooling delle connessioni (PgBouncer) Un servizio middleware che si trova di fronte a Postgres. Contiene 1.000 connessioni client ma le mappa su 10 connessioni DB reali. DigitalOcean e AWS RDS Proxy lo offrono come servizio.

Soluzione 2: database basati su HTTP Nuovi fornitori di database (Neon, PlanetScale, Supabase) offrono API HTTP. Non si apre un socket TCP. Puoi recuperare('https://db.neon.tech/query'). HTTP è senza stato. Si adatta perfettamente a Serverless.

“dattiloscritto”. // Utilizzo di Neon (Postgres serverless) importa { neon } da ‘@neondatabase/serverless’;

const sql = neon(process.env.DATABASE_URL);

esporta il gestore della funzione asincrona (evento) { risultato const = attendi sqlSELECT * FROM users; return {corpo: JSON.stringify(risultato)}; }


## Gestione dello stato: non c'è memoria

In un server normale, puoi fare:
`let requestCount = 0; app.get('/', () => requestCount++);`
In Serverless, "requestCount" sarà sempre effettivamente 1 o 0.
Il contenitore viene distrutto dopo l'esecuzione. Le variabili globali vengono cancellate.

**Regola**: tutti gli stati devono essere esterni.
* Dati sessione -> **Redis**.
* Dati utente -> **Database**.
* Caricamenti di file -> **S3/Archiviazione BLOB**.
Non scrivere in `/tmp` (svanisce). Non utilizzare variabili globali.

## Analisi dei costi: il punto critico

Il serverless non è sempre più economico.
Ha un "Markup" sul calcolo grezzo (~ 2x costo per ciclo CPU rispetto a EC2).
Il risparmio deriva dallo **0% di tempo di inattività**.

* **Traffico basso/Traffico intenso**: Serverless è più economico del 90%.
* **Carico elevato costante**: se hai un processo in esecuzione 24 ore su 24, 7 giorni su 7 (come un server WebSocket o un'intensa elaborazione dei dati), EC2 è più economico.
Eseguiamo audit TCO (costo totale di proprietà) per i clienti. Spesso, il costo operativo della gestione di EC2 (patch, sicurezza) rende Serverless il vincitore anche a volumi più elevati.

## Codice: percorso API Vercel (migliore pratica)

Strutturiamo le nostre funzioni affinché siano testabili, separando la Logica dalla Rete.

"dattiloscritto".
// app/api/checkout/route.ts (router dell'app Next.js)
importa { NextResponse } da 'next/server';
import { createCheckout } da '@/lib/checkout'; // Logica aziendale

// Il gestore (livello di rete)
esporta la funzione asincrona POST(richiesta: Richiesta) {
  prova {
    const body = attendono request.json();
    
    // Convalida l'input (Zod)
    se (!body.cartId) {
      return NextResponse.json({ errore: 'ID carrello mancante' }, { status: 400 });
    }

    // Chiama la logica
    const url = attendono createCheckout(body.cartId);

    return NextResponse.json({url});
  } cattura (errore) {
    console.errore(errore); // Registra su CloudWatch/Datadog
    return NextResponse.json({ errore: 'Errore interno' }, { status: 500 });
  }
}

10. Osservabilità: tracciamento distribuito

In un monolite, grep server.log. In Serverless, una richiesta di un singolo utente raggiunge API Gateway -> Lambda A -> SQS -> Lambda B -> DynamoDB. Se fallisce, dove ha fallito? Non è possibile eseguire il grep dei log su 5 servizi. Implementiamo il Tracciamento distribuito (OpenTelemetry / AWS X-Ray). Passiamo un’intestazione trace_id attraverso ogni servizio. Questo genera un “grafico Flame” che mostra esattamente dove si è verificato il picco di latenza (ad esempio, “Lambda B ha impiegato 3 secondi perché DynamoDB era in throttling”).

11. Il mito del vincolo del fornitore

I revisori dicono spesso: “Serverless ti blocca in AWS”. VERO. Ma Docker ti blocca nel kernel Linux. React ti blocca nel DOM virtuale. Il lock-in è inevitabile. La domanda è: “Il lock-in vale la velocità?” Possiamo riscrivere una funzione Lambda in Go/Rust in 1 giorno. Il costo della migrazione lontano da Serverless è basso perché le unità di codice sono piccole. Il costo del non utilizzo di Serverless (gestione delle flotte EC2) è elevato e continuo.

13. Sicurezza: privilegio minimo (IAM)

Una Lambda = Un ruolo. Non fornire al tuo Lambda “AdministratorAccess”. Se quel Lambda è compromesso (Dependency injection), l’aggressore possiede il tuo account. Dagli: s3:GetObject SOLO su bucket-a. Questo modello di sicurezza granulare è superiore a un Monolith in cui l’intero server ha accesso root al DB. Strumenti come SST (Serverless Stack) automatizzano questa generazione di policy: bucket.grantRead(lambda) genera automaticamente la rigorosa policy IAM.

14. Framework: perché utilizziamo SST

Raw CloudFormation è doloroso. Terraform è dettagliato. Utilizziamo SST (Serverless Stack). Ci consente di definire l’infrastruttura in TypeScript. Abilita “Live Lambda Development” (proxy dell’ambiente locale su AWS). Imposti i punti di interruzione in VS Code, raggiungi un endpoint e si ferma all’interno di Lambda in esecuzione su AWS. È l’unico modo per sviluppare Serverless in modo sano.

15. Conclusione

Le funzioni serverless sono il collante della moderna Internet. Consentono agli ingegneri frontend di diventare “Full Stack” senza bisogno di una laurea in amministrazione Linux. Si adattano all’infinito. Non costano nulla quando sono inattivi. Ma richiedono una mentalità “apolide” disciplinata.

Paghi per il tempo di attività inattivo?

Gestisci un server da € 100 per un lavoro che richiede 5 secondi al giorno? Assumi i nostri architetti.