Serverless: come ha cambiato (per sempre) il modo di fare deploy

C’è un prima e un dopo nella storia del deploy. La linea non è netta come un lancio di prodotto, ma se dovessi indicare un punto di rottura, direi intorno al 2015 — quando AWS Lambda è diventato pubblicamente disponibile e ha cambiato le coordinate del problema.

Prima di allora, deployare un’applicazione significava gestire l’infrastruttura che la ospitava. Dopo, è diventato un problema di codice.

Il mondo prima: server, processi, e molta ansia

Il deploy tradizionale — che fosse su un VPS, un server bare metal o una macchina EC2 — richiedeva di pensare a livelli che non avevano nulla a che fare con l’applicazione in sé:

• Quanta RAM ha il server? Regge il picco di traffico?
• Il processo è ancora vivo? Serve un supervisor (pm2, systemd, supervisord)?
• Come gestisco il downtime durante il deploy?
• Se scala, come bilancio il carico?

La lista era lunga. E anche con Docker, che ha semplificato molto la portabilità, il problema di dove e come far girare quel container rimaneva interamente tuo.

Un deploy a zero downtime su un VPS singolo richiedeva configurazione manuale di nginx, un processo di rolling, health check — roba che ti portava via mezza giornata e che dovevi documentare per non dimenticarla.

Serverless: il cambio di prospettiva

Il modello serverless ribalta la questione. Non esiste un server da gestire — esiste una funzione da eseguire.

// Una Lambda function in TypeScript
export const handler = async (event: APIGatewayProxyEvent) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "ok" }),
  };
};

Questa funzione:

• Non ha un processo che gira h24
• Non occupa RAM quando non viene chiamata
• Scala automaticamente da 0 a migliaia di istanze parallele
• Costa esattamente quanto viene usata (il famoso pay-per-invocation)

Il deploy di questa funzione è un comando:

# Con SST (framework moderno per serverless su AWS)
npx sst deploy --stage production

Fatto. L’infrastruttura viene costruita e gestita dal cloud provider. Il team non ha bisogno di un DevOps dedicato per tenere su i server.

L’impatto concreto sul processo di deploy

1. Deploy frequenti diventano normali

Quando non devi fare i conti con downtime, processi da riavviare e configurazioni da sincronizzare, il costo psicologico di un deploy scende drasticamente.

Con Vercel, Netlify o Cloudflare Workers, ogni push su main è un deploy. Non è una pipeline complessa — è il default. Ho lavorato su progetti dove si deployava 10-15 volte al giorno senza pensarci due volte.

2. Preview environments gratuitamente

Un cambio di paradigma che spesso si sottovaluta: ogni PR ottiene automaticamente un ambiente di preview con URL dedicata.

PR #42 → https://pr-42.mio-progetto.vercel.app

Prima, testare una feature in un ambiente reale richiedeva un server di staging dedicato — infrastruttura da pagare e mantenere. Oggi è incluso nella piattaforma.

3. Il rollback è tornare indietro di un commit

Nei deploy tradizionali, un rollback significava rideployare la versione precedente, gestire le migrazioni del database al contrario, sperare che tutto tornasse uguale. Un’operazione a rischio.

Con serverless e deploy immutabili, ogni deployment è uno snapshot. Tornare alla versione precedente è letteralmente un clic o un comando:

vercel rollback

4. La superficie di attacco si riduce

Con server persistenti, un processo compromesso rimane compromesso fino a quando non viene riavviato. Le funzioni serverless sono stateless per design: ogni invocazione parte da zero, nessun dato persiste in memoria tra una chiamata e l’altra.

Non è sicurezza perfetta, ma il modello riduce strutturalmente alcune classi di vulnerabilità.

I limiti che nessuno menziona nei tutorial

Il serverless non è la risposta a tutto. Ci sono trade-off reali.

Cold start. Una funzione che non viene invocata da un po’ ci mette qualche centinaio di millisecondi ad avviarsi. Per Lambda con runtime pesanti (Java, .NET) può arrivare a secondi. Non adatto a tutto.

Stato. Niente stato in memoria. Ogni cosa che deve persistere tra le invocazioni va su un database o un key-value store esterno. Architetturalmente è più pulito, ma aggiunge latenza e dipendenze.

Debug locale. Emulare un ambiente serverless in locale è migliorato molto (SST, Serverless Framework, Wrangler per Workers), ma rimane più complesso di un normale npm run dev.

Vendor lock-in. Una Lambda con 50 servizi AWS intorno non si migra in una settimana. Scegliere serverless significa scegliere un ecosistema.

Dove siamo oggi

Il serverless ha vinto per la maggior parte dei casi d’uso web standard — API, webhook, siti statici con funzioni edge, background jobs. La complessità operativa che prima richiedeva figure dedicate (sysadmin, DevOps) è stata assorbita dai cloud provider.

Il developer oggi pusha codice. L’infrastruttura è un dettaglio di configurazione, non un lavoro a tempo pieno.

È un cambio di ruolo più che di tecnologia. E per chi ha vissuto i due mondi, la differenza si sente ogni giorno.