Cos'è FaaS (Function as a Service)?

FaaS è il modello di esecuzione in cui il codice gira come funzioni effimere attivate da eventi, senza server da predisporre né da gestire. Lo sviluppatore pubblica una funzione, dichiara quale evento la avvia (una richiesta HTTP, un file caricato in uno storage, un messaggio in coda, una schedulazione) e quanta memoria le serve; il provider alloca le risorse all'arrivo dell'evento, esegue la funzione e le rilascia quando termina, riducendo tutto a zero quando non c'è traffico. La fatturazione segue lo stesso principio: si paga per invocazione e tempo di esecuzione, non per capacità prenotata. Il pioniere è AWS Lambda, lanciato nel 2014, oggi affiancato dalle funzioni degli altri grandi cloud e da alternative open source come Knative e OpenFaaS. FaaS è un sottoinsieme del serverless: tutto il serverless nasconde i server, ma solo FaaS riduce l'unità di esecuzione alla singola funzione guidata da eventi: il gradino sopra PaaS e IaaS dove si scrive codice.

Leggi anche: Serverless vs On-prem vs Edge · Tre modelli di deployment: paghi a esecuzione nel cloud, possiedi l'infrastruttura in casa, o porti il calcolo vicino ai dati.

Come funziona: trigger, esecuzione effimera e limiti

La prima esecuzione dopo un periodo di inattività paga il cold start: il provider deve preparare l'ambiente di runtime prima di eseguire il codice, quindi la risposta arriva più tardi; le successive riusano l'ambiente caldo e sono veloci. Per questo FaaS ama il traffico intermittente e soffre i percorsi sincroni a latenza rigida. È il braccio esecutivo dell'architettura a eventi: il trigger è un fatto già avvenuto, la funzione reagisce e sparisce. La seconda regola è che le funzioni non tengono stato: nessuna invocazione può presumere che qualcosa in memoria sopravviva tra un'invocazione e l'altra, quindi lo stato vive in servizi esterni (database, code, storage). La terza è che i limiti sono stretti e non negoziabili: su AWS Lambda un'esecuzione non supera i 15 minuti, la memoria va da 128 MB a 10 GB con CPU proporzionale e il payload sincrono è di pochi megabyte; oltre queste soglie il lavoro va spezzato o spostato su container. Il rovescio operativo è il debug: in locale mancano le sorgenti di eventi del provider e gli emulatori divergono dal comportamento reale, così i problemi emergono in produzione. E il lock-in passa dai trigger: funzioni cablate su code, permessi e servizi satellite di un solo cloud si portano via solo riscrivendone i contorni. Chi vuole la stessa semantica su infrastruttura propria può usare Knative o OpenFaaS su Kubernetes, al prezzo di gestire la piattaforma in casa.

Un esempio enterprise

Una PMI con un gestionale che ogni notte ricalcola giacenze e listini e un sito che riceve poche decine di ordini al giorno può mettere il ricalcolo su una funzione schedulata e l'invio degli ordini su una funzione chiamata dal webhook del sito. Tra un ordine e l'altro non gira nulla e non si paga nulla; nei picchi, dopo una campagna, il provider apre tante istanze in parallelo senza server previsti in anticipo. Il confronto è con un server sempre acceso: con poche migliaia di esecuzioni brevi al mese il pay-per-use vince, mentre se il carico diventasse costante e pesante la macchina fissa tornerebbe più economica.

Perché conta per chi decide

Per chi decide, FaaS sposta la domanda da quanta capacità comprare a quanto è intermittente il carico: picchi imprevedibili e volumi bassi lo premiano, traffico costante e latenze rigide lo puniscono. La scelta tra modelli di deployment resta però più ampia delle funzioni: quando FaaS basta e quando serve infrastruttura dedicata è la decisione tra modelli, con i suoi quattro assi. Quelle esposte via HTTP arrivano dietro un gateway che governa accessi e limiti, e il conto va tenuto con disciplina FinOps perché il pay-per-use senza tetto cresce in silenzio.