Cosa sono serverless e FaaS

Cos'è il serverless computing

Il serverless computing è un modello di cloud computing in cui il provider cloud gestisce automaticamente l'infrastruttura. A differenza del web hosting classico, gestisce per te lo scaling e l'allocazione delle risorse. Nonostante il nome, i server esistono ancora, ma non devi pensarci né configurarli. Tu scrivi il codice, lo deployi e il provider cloud si occupa di tutto il resto, incluso sistema operativo, ambiente di runtime, scaling e alta disponibilità. Paghi solo per il tempo di esecuzione del codice, non per il tempo in cui il server attende le richieste.

Il serverless è un'evoluzione che parte dai server fisici, passa per le macchine virtuali e i container fino a un modello di computing completamente astratto. Ogni passo di questa evoluzione rimuove un livello di responsabilità dallo sviluppatore e lo trasferisce al provider cloud. Nel modello serverless lo sviluppatore si concentra esclusivamente sulla logica di business mentre il provider cloud si occupa di tutto il resto, accelerando drasticamente lo sviluppo e riducendo i costi operativi per molti tipi di applicazione.

Functions as a Service (FaaS)

FaaS è la forma più riconoscibile di serverless computing. Nel modello FaaS scrivi funzioni piccole e indipendenti che vengono eseguite in risposta a eventi. Ogni funzione ha una responsabilità chiaramente definita, riceve dati in input, esegue la logica e restituisce un risultato. Il provider cloud crea automaticamente un'istanza per l'esecuzione della funzione, la esegue e spegne l'istanza al termine. Se arrivano 1000 richieste simultanee, il provider crea automaticamente 1000 istanze.

Principali provider FaaS

• AWS Lambda - primo e più maturo servizio FaaS, lanciato nel 2014
• Google Cloud Functions - il FaaS di Google con buona integrazione Firebase
• Azure Functions - il FaaS di Microsoft con eccellente supporto .NET
• Cloudflare Workers - edge computing con distribuzione globale e isolamento V8
• Vercel Functions - ottimizzato per Next.js e i framework frontend
• Netlify Functions - semplice per i siti Jamstack

Ogni provider ha specificità riguardo a linguaggi di programmazione supportati, tempo massimo di esecuzione, limiti di memoria e metodi di trigger. Per un approccio più classico, valuta il servizio di cloud hosting. AWS Lambda supporta Node.js, Python, Java, Go, .NET e Ruby con un tempo massimo di esecuzione di 15 minuti e fino a 10 GB di memoria. Cloudflare Workers usa il runtime V8 con un limite di tempo CPU di 50 ms (piano gratuito) ma con latenza estremamente bassa, perché viene eseguito su edge location.

Come funzionano le funzioni serverless

Quando un evento attiva una funzione serverless, il provider cloud attraversa diverse fasi. Per prima cosa, verifica se esiste un'istanza calda già inizializzata e pronta all'esecuzione. In caso contrario, viene creata una nuova istanza, chiamata cold start. Il cold start include l'avvio del container, il caricamento del runtime, il caricamento del tuo codice e l'esecuzione della logica di inizializzazione. Dopodiché, la funzione handler viene eseguita con i dati dell'evento.

Il problema del cold start

Il cold start è la fonte più comune di latenza nell'architettura serverless. Per le funzioni Node.js il cold start richiede di solito 100-500 ms, per Python 200-800 ms, e per Java può essere di 1-5 secondi o più a causa dell'inizializzazione della JVM. Dopo la prima esecuzione, l'istanza rimane calda per un certo tempo (di solito 5-15 minuti) e le richieste successive vengono eseguite molto più rapidamente perché saltano l'inizializzazione.

Le strategie per ridurre il cold start includono l'uso di runtime leggeri (Node.js e Python sono più veloci di Java), la minimizzazione delle dimensioni del pacchetto di deployment, l'uso della provisioned concurrency (pagando per istanze pre-riscaldate) e l'evitare inizializzazioni pesanti nella funzione handler. AWS Lambda SnapStart per Java e Cloudflare Workers che usa gli isolate V8 invece dei container riducono significativamente il cold start a un livello trascurabile per la maggior parte delle applicazioni.

Casi d'uso del serverless

L'architettura serverless è ideale per certi tipi di workload mentre per altri può essere costosa o poco pratica. Comprendere il caso d'uso giusto è fondamentale per applicare con successo il modello serverless nella pratica.

Scenari ideali

• Backend di API - API REST o GraphQL che gestiscono richieste HTTP
• Elaborazione di eventi - reagire a upload di file, modifica del database, messaggio in coda
• Task pianificati - cron job eseguiti periodicamente
• Elaborazione di immagini e video - ridimensionamento, compressione, transcodifica on demand
• Chatbot e inferenza AI - elaborazione dei messaggi degli utenti e chiamate a modelli AI
• Webhook - ricezione ed elaborazione di chiamate webhook da servizi esterni
• Elaborazione di dati IoT - elaborazione di dati da sensori e dispositivi

Scenari meno adatti

Il serverless non è ottimale per i processi a lunga esecuzione che durano più di 15 minuti, per le applicazioni che richiedono una latenza costantemente bassa (problema del cold start), per i workload con traffico costantemente elevato dove un server dedicato è più economico, e per le applicazioni che richiedono un filesystem locale o connessioni WebSocket di lunga durata. In questi casi, i container o i server tradizionali sono una scelta migliore.

Modello di prezzo

Uno dei maggiori vantaggi del modello serverless è il pay-per-use. Non paghi per il tempo di inattività del server ma solo per il tempo in cui il tuo codice è effettivamente in esecuzione. AWS Lambda addebita in base al numero di richieste (0,17 EUR per milione di richieste) e in base alla durata dell'esecuzione misurata in GB-secondi (quanta memoria usa la funzione moltiplicata per la durata dell'esecuzione in secondi).

Confronto dei costi

Per un piccolo sito o un'API con 100.000 richieste al mese dove ogni richiesta dura 200 ms con 256 MB di memoria, il costo mensile su AWS Lambda sarebbe inferiore a un euro. Il server EC2 equivalente t3.micro costa circa 7,30 EUR al mese anche quando per la maggior parte del tempo non fa nulla. Per questo tipo di workload, il serverless è drasticamente più economico.

Tuttavia, il calcolo cambia su larga scala. Per un'applicazione con 100 milioni di richieste al mese, i costi del serverless possono superare i 170 EUR al mese mentre un server dedicato con capacità simile costerebbe meno. Il cosiddetto serverless cost cliff si verifica quando il workload supera una certa soglia oltre la quale un server affittato in modo costante diventa più conveniente. Per ogni applicazione è importante fare un'analisi dei costi per il workload previsto prima di scegliere un modello.

Vantaggi dell'architettura serverless

• Nessuna gestione dell'infrastruttura - non ti preoccupi di server, patch, scaling
• Scaling automatico - da zero a un milione di richieste senza alcuna configurazione
• Pay-per-use - paghi solo per l'esecuzione, non per il tempo di inattività
• Sviluppo più rapido - concentrarsi sul codice invece che sull'infrastruttura accelera la consegna
• Alta disponibilità - il provider cloud garantisce la disponibilità senza il tuo coinvolgimento
• Scaling a zero - nessun costo quando non c'è traffico

Svantaggi e sfide

L'architettura serverless porta anche sfide specifiche. Il vendor lock-in è reale, perché ogni provider ha API, servizi e strumenti specifici che rendono difficile la migrazione verso un altro provider. La latenza da cold start può essere problematica per le applicazioni che richiedono una risposta costantemente rapida. Il debugging e il monitoraggio sono più complessi, perché le funzioni vengono eseguite in ambienti effimeri senza accesso ai tradizionali strumenti diagnostici.

Anche lo sviluppo e il testing in locale rappresentano una sfida, perché è difficile replicare localmente l'ambiente cloud. Strumenti come AWS SAM, Serverless Framework e LocalStack aiutano ma non possono simulare completamente il comportamento in produzione. I limiti sulle dimensioni del pacchetto di deployment, sul tempo di esecuzione e sulla memoria possono richiedere il refactoring delle applicazioni esistenti. Infine, per i team senza esperienza con i servizi cloud, la curva di apprendimento può essere ripida.