Un picco di ordini arriva dopo una campagna, ma nei giorni normali i server restano quasi inutilizzati: per un’azienda, il serverless computing può ridurre il lavoro di gestione e adattare le risorse alla domanda, purché l’applicazione tolleri bene avvii, retry e dipendenze dal cloud provider. Il punto è capire se il carico è davvero variabile o se, dietro la promessa del pagamento a consumo, si nasconde un servizio sempre acceso.
Il serverless conviene quando il carico segue eventi e domanda variabile
- Infrastruttura gestita: il provider si occupa dei server, mentre il team resta responsabile di codice, dati, sicurezza e configurazione.
- Uso ideale: elaborazioni a eventi, attività pianificate e servizi con picchi di traffico o periodi di inattività.
- Costi: il pagamento a consumo può aiutare, ma database, rete, log e concorrenza entrano nel conto complessivo.
- Rischi tecnici: avvii a freddo, eventi duplicati e dipendenza dai servizi proprietari richiedono contromisure.
- Scelta pratica: avvia un progetto pilota su un flusso circoscritto prima di spostare un’intera applicazione.
Il provider gestisce i server, ma il lavoro operativo non sparisce
Immagina un sistema che riceve un ordine, genera una fattura e invia una notifica. Con un’architettura serverless, ciascun passaggio può partire da un evento e usare risorse cloud solo quando serve; la gestione di macchine e capacità passa al provider. Serverless non significa assenza di server: significa che il team non deve amministrarli direttamente.
La forma più nota è la Function as a Service (FaaS), in cui una funzione esegue un compito in risposta a una richiesta o a un evento. L’approccio comprende anche servizi gestiti per database, code, autenticazione e archiviazione. La Cloud Native Computing Foundation descrive il modello come un’astrazione che delega al provider gestione operativa, provisioning e scalabilità.
Restano però a carico dell’azienda la logica applicativa, i permessi, la protezione dei dati, il monitoraggio e la qualità delle integrazioni. Si sposta il confine operativo, non la responsabilità sul risultato: è una distinzione che pesa quando un processo automatizzato modifica ordini, pagamenti o dati dei clienti.
Il serverless è adatto ai carichi a eventi, meno ai servizi sempre accesi
Una funzione che parte al caricamento di un documento ha un profilo diverso da un servizio che riceve richieste continue tutto il giorno. Nel primo caso, la capacità può seguire eventi intermittenti; nel secondo, istanze sempre attive o container gestiti possono risultare più semplici da prevedere. Il tipo di carico orienta la scelta più dell’etichetta tecnologica.
| Situazione | Possibile effetto | Come decidere |
|---|---|---|
| Traffico sporadico o picchi imprevedibili | Le risorse possono ridursi nei periodi di inattività e aumentare quando arrivano richieste. | Valuta una funzione o un servizio serverless; controlla anche costi di rete, archiviazione e database. |
| Carico stabile e continuo | Il consumo a richiesta può offrire meno vantaggi e rendere meno immediata la previsione dei costi. | Confronta il costo totale con un servizio a capacità riservata o un container sempre attivo. |
| Risposte con latenza molto prevedibile | Un ambiente che deve inizializzarsi può introdurre ritardi nelle invocazioni a freddo. | Misura la latenza al percentile richiesto dal servizio e considera capacità preinizializzata o un’alternativa sempre attiva. |
| Operazione non sicura se ripetuta | Retry o consegne duplicate possono registrare due volte un pagamento o un ordine. | Progetta la funzione perché riconosca gli eventi già elaborati prima di avviare la scrittura. |
Un caso adatto può essere la conversione di immagini caricate dai clienti: ogni nuovo file attiva l’elaborazione, senza tenere un server dedicato in attesa. Credo che un flusso circoscritto di questo tipo sia un banco di prova migliore della migrazione immediata del gestionale: il risultato si misura senza distribuire rischi su tutta l’azienda.
Il costo va misurato sul processo completo, non sulla sola funzione
Una fattura cloud apparentemente leggera può crescere quando si sommano esecuzioni, durata, memoria, richieste verso altri servizi, trasferimento dati e conservazione dei log. I modelli di prezzo dipendono dal provider e dalla configurazione: per esempio, Google Cloud Run calcola il costo in base alle risorse utilizzate e considera anche la concorrenza delle richieste. Il costo della funzione da solo non basta per decidere.
Per confrontare le opzioni, prendi un flusso reale e registra quante volte viene eseguito, quanto dura e quali servizi chiama. Poi confronta il totale con il costo dell’alternativa attuale, includendo capacità inutilizzata e tempo operativo del team; per evitare false economie, misura lo stesso periodo e lo stesso volume di lavoro.
La regola pratica è semplice: se il carico è intermittente e il costo dell’infrastruttura inattiva è rilevante, il modello serverless merita un test. Se il carico è costante, i tempi devono restare stretti o le dipendenze generano molta comunicazione di rete, metti a confronto anche container e servizi sempre attivi. Una stima senza telemetria è solo un’ipotesi.
Retry e avvii a freddo richiedono una progettazione esplicita
Il primo avvio dopo un periodo di inattività può richiedere più tempo di quelli successivi: questa latenza è detta cold start. Nella documentazione di AWS Lambda, la preparazione dell’ambiente di esecuzione è descritta come una fase che può aggiungere latenza; la frequenza e la durata variano in base alla funzione e al carico. Se una risposta deve essere rapida in modo prevedibile, misura il caso peggiore rilevante per il servizio, non soltanto la media.
C’è poi un rischio meno evidente del ritardo: lo stesso evento può essere consegnato più di una volta. Le linee guida AWS per progettare applicazioni con Lambda raccomandano funzioni idempotenti, cioè capaci di ricevere nuovamente lo stesso evento senza ripetere l’effetto. Per una fattura, ad esempio, un identificativo univoco dell’ordine può impedire la creazione di duplicati.
Prima del rilascio, verifica anche timeout, limiti di concorrenza, gestione degli errori, autenticazione e tracciamento degli eventi. Un retry automatico non corregge una logica fragile: può amplificarne l’effetto se il codice non distingue un’operazione già completata da una nuova.
Il lock-in si riduce isolando la logica dai servizi proprietari
Il vincolo al provider raramente nasce dal codice della funzione in sé; spesso si accumula nelle integrazioni con code, database, workflow e permessi specifici della piattaforma. Nei confronti tra sviluppatori ricorrono proprio queste preoccupazioni, insieme alla difficoltà di testare in locale e diagnosticare flussi distribuiti. La comodità iniziale può trasformarsi in costo di migrazione se ogni componente dipende da API proprietarie.
Per contenere il rischio, separa la logica di business dagli adattatori cloud, usa formati di evento documentati e conserva test che possano essere eseguiti senza l’ambiente di produzione. Non serve rinunciare a ogni servizio gestito: conviene piuttosto decidere consapevolmente quali dipendenze proprietarie producono un vantaggio abbastanza forte da giustificare il vincolo.
Il sondaggio annuale CNCF 2024, basato su 689 risposte valide alla domanda sull’uso di serverless e FaaS, rilevava il modello in produzione per alcune applicazioni nel 44% delle organizzazioni partecipanti; l’11% lo usava per la maggior parte o per tutte le applicazioni. Il dato suggerisce una strategia pragmatica: adozione selettiva, non migrazione totale. È una fotografia del campione, non una previsione per ogni azienda italiana.
La decisione migliore parte da un flusso piccolo e misurabile
Scegli un processo con confini chiari, come l’elaborazione di un file o l’invio di notifiche, e definisci prima i criteri di riuscita: costo per operazione, latenza, tasso di errore e tempo necessario per diagnosticare un guasto. Se questi indicatori migliorano senza peggiorare sicurezza e manutenzione, estendi il modello; se emergono ritardi o costi difficili da controllare, mantieni quel carico su un servizio sempre attivo.Il serverless può liberare il team dalla gestione della capacità, ma non elimina le decisioni architetturali. Il test più utile non è “funziona?”: è “funziona a un costo, con una latenza e con un livello di controllo accettabili per questo processo?”.