Serverless non significa risparmiare sempre. Significa risparmiare quando il carico è imprevedibile. Con carichi costanti, i container vincono nettamente. Ecco i numeri per decidere senza sbagliare.
Panoramica in 20 secondi
Marco gestisce lo sviluppo tecnologico di un e-commerce milanese che vende accessori per ciclismo. Il suo team è composto da tre sviluppatori. Fino a due anni fa, mantenevano due macchine virtuali su AWS: una per le API, una per i job notturni di sincronizzazione con il gestionale Zucchetti. Ogni mese, quelle macchine costavano circa 180 euro anche quando — e succedeva spesso — restavano sostanzialmente inattive per ore. Il problema non era il costo in sé, ma il rapporto tra quello che pagavano e quello che ottenevano. Poi Marco ha spostato i job notturni su AWS Lambda, il servizio di calcolo serverless di Amazon dove carichi il tuo codice e lui lo esegue solo quando viene invocato. Nessun sistema operativo da aggiornare, nessun server da dimensionare. Il costo dei job notturni è passato da 60 euro al mese a meno di 4 euro. La parola serverless crea un equivoco immediato: sembra che i server non esistano. Esistono eccome, ma li gestisce il provider cloud. Tu scrivi la funzione, definisci quando deve attivarsi — una richiesta HTTP, un file caricato su uno storage, un messaggio in coda — e il resto è trasparente. AWS Lambda è il più diffuso, ma nel 2026 le alternative mature sono diverse: Google Cloud Functions, Azure Functions, Cloudflare Workers per l'edge computing. Ognuno ha le sue specificità, ma il principio è identico: paghi per millisecondo di esecuzione, non per ora di server acceso.
I vantaggi operativi sono reali e misurabili. Lo scaling è automatico: se arrivano dieci richieste al minuto o diecimila, il provider alloca le risorse necessarie senza che tu tocchi nulla. Il deploy avviene in secondi — carichi una funzione aggiornata e in trenta secondi è in produzione. Non devi applicare patch al sistema operativo, non devi aggiornare il runtime, non devi preoccuparti di bilanciatori di carico. Per un team piccolo, questo significa liberare ore che prima finivano in manutenzione infrastrutturale e reinvestirle nello sviluppo del prodotto. Ma ecco dove il racconto entusiastico si ferma e inizia la realtà di chi queste architetture le usa ogni giorno. Il cold start — il tempo che passa tra la prima invocazione e la risposta della funzione — su Lambda con connessione a una VPC (la rete privata virtuale dentro AWS) oscilla tra 150 e 800 millisecondi. Per un job notturno è irrilevante; per un endpoint API che un utente chiama aspettandosi risposta in meno di 200 millisecondi, è un problema serio. Poi ci sono i timeout massimi: Lambda ti concede al massimo 15 minuti di esecuzione per invocazione, Cloud Run arriva a 60 minuti. Se il tuo processo dura di più, serverless semplicemente non funziona.
Il punto più critico, quello che raramente compare nelle presentazioni commerciali dei cloud provider, è il vendor lock-in. Quando scrivi una funzione Lambda, non stai solo usando un runtime: stai usando il sistema di trigger di AWS (EventBridge, SQS, API Gateway), il formato di evento specifico di Lambda, le policy IAM di AWS. Riscrivere tutto per Cloud Functions di Google non è questione di cambiare tre righe di configurazione — è un progetto di migrazione che può richiedere settimane. E poi ci sono i costi a regime. Un confronto che facciamo spesso con le aziende: un endpoint API che riceve 100.000 richieste al giorno costa circa 12 euro al mese su Lambda. Lo stesso endpoint su un container ospitato su Fly.io costa circa 45 euro. Fin qui, serverless vince nettamente. Ma quando le richieste salgono a 10 milioni al giorno — un volume che molte piattaforme B2C raggiungono durante le campagne promozionali — il conto si ribalta: circa 800 euro al mese su Lambda contro circa 200 euro su container. La regola empirica è semplice: sotto il milione di invocazioni giornaliere, serverless costa meno; sopra, il container diventa molto più conveniente. E il confine non è fisso, dipende dalla durata media di ogni esecuzione e dalla memoria allocata.
La domanda che gli imprenditori e i responsabili IT dovrebbero porsi non è se usare serverless oppure container, ma dove usare l'uno e dove l'altro. Nel 2026, il pattern architetturale più efficace per le imprese italiane di medie dimensioni è ibrido: serverless per i carichi di lavoro event-driven e imprevedibili, container per tutto ciò che è costante e sensibile alla latenza. Prendiamo un caso concreto che illustra bene questa logica. Un'azienda e-commerce di Brescia che vende prodotti per la casa gestisce circa 30.000 ordini al mese. Il flusso core — il catalogo prodotti, il carrello, il checkout — gira su container ECS (Elastic Container Service di AWS), tre istanze sempre attive con bilanciamento del carico. Queste API rispondono in meno di 80 millisecondi, il costo è prevedibile e fisso. Ma tutto quello che succede dopo il checkout è gestito da Lambda: una funzione aggiorna l'ERP (nel loro caso Oracle NetSuite), un'altra notifica il magazzino via webhook, una terza genera e invia l'email di conferma al cliente, una quarta aggiorna il feed per Google Merchant Center. Questo pattern si chiama fan-out: un singolo evento — l'ordine confermato — scatena più funzioni in parallelo, ognuna indipendente. Se l'invio email fallisce, la notifica al magazzino non ne risente. Se il feed Google ha un ritardo, l'ERP si aggiorna comunque. Il costo complessivo dell'infrastruttura di questa azienda, inclusi container e funzioni serverless, sta sotto i 200 euro al mese per 30.000 ordini gestiti.
Un altro pattern che vediamo applicare con frequenza crescente è il processing asincrono di file. Immagina un'azienda manifatturiera che riceve ordini via PDF dai propri distributori. Il flusso tradizionale prevede qualcuno che apre il PDF, estrae i dati, li inserisce nel gestionale. Con un'architettura serverless, il PDF viene caricato su uno storage cloud (S3, Cloud Storage), l'upload attiva automaticamente una funzione Lambda che invoca un servizio di estrazione testo (Textract di AWS o Document AI di Google), i dati estratti vengono validati da una seconda funzione e poi inseriti nel gestionale tramite API. Se arrivano 5 PDF in un giorno o 500, il sistema scala da solo. Quando non arriva niente, il costo è zero. Per orchestrare flussi più complessi — dove una funzione deve aspettare il risultato di un'altra, gestire errori, implementare retry con backoff — entrano in gioco i servizi di orchestrazione: AWS Step Functions, Google Workflows, Azure Durable Functions. Questi servizi permettono di definire il flusso come una macchina a stati: se lo step 2 fallisce, torna allo step 1 con un ritardo di 30 secondi; se fallisce tre volte, manda un alert su Slack e mette l'ordine in coda manuale. Senza orchestrazione, gestire questi scenari in Lambda puro diventa un incubo di callback annidati e stati inconsistenti che nessun team piccolo vuole mantenere.
La scelta tra serverless e container non è una decisione tecnica pura — è una decisione di business che dipende dal profilo di carico, dalla dimensione del team e dalla tolleranza ai costi variabili. Se il tuo team ha due sviluppatori e il carico è imprevedibile, serverless riduce drasticamente il lavoro operativo e i costi a riposo. Se hai un team DevOps strutturato e carichi costanti, Kubernetes con container ottimizzati ti dà più controllo e costi più bassi a regime. La maggior parte delle aziende italiane tra 10 e 200 dipendenti che abbiamo visto adottare cloud in modo maturo nel 2026 finisce con un'architettura ibrida: un nucleo containerizzato per i servizi critici e un layer serverless per tutto ciò che è reattivo, temporaneo o integrativo. Il consiglio pratico è partire mappando i propri workload su due assi — frequenza di esecuzione e sensibilità alla latenza. Tutto ciò che è frequente e latency-sensitive va su container. Tutto ciò che è sporadico, event-driven o parallelizzabile è territorio serverless. Questa mappa diventa il documento decisionale più utile che un responsabile IT possa avere sul tavolo quando parla con il proprio cloud architect o con il partner tecnologico che progetta l'infrastruttura.
Con il modello serverless paghi esclusivamente per i millisecondi di esecuzione effettiva del codice. Nessun costo per server inattivi, nessun canone fisso per capacità inutilizzata. Per carichi sporadici come webhook, cron job o processing notturno, il risparmio rispetto a macchine virtuali sempre accese supera regolarmente l'80 percento.
Un singolo evento — un ordine, un upload, un pagamento — attiva decine di funzioni in parallelo senza che tu gestisca code o worker. Ogni funzione opera in modo indipendente: se una fallisce, le altre proseguono. Questo pattern elimina i colli di bottiglia tipici dei monoliti e rende i flussi post-transazione robusti e scalabili senza intervento manuale.
Italy Soft progetta architetture che combinano container per i servizi core a bassa latenza e funzioni serverless per i workload reattivi e variabili. Questa impostazione ibrida permette alle PMI italiane di mantenere costi infrastrutturali contenuti — spesso sotto i 200 euro al mese — senza sacrificare le prestazioni sugli endpoint critici per il business.
Servizi come AWS Step Functions o Google Workflows permettono di definire flussi complessi con gestione automatica di errori, retry e timeout. Invece di scrivere logica di coordinamento dentro ogni funzione, dichiari il flusso visivamente: se uno step fallisce tre volte, il sistema esegue un'azione alternativa. Meno codice da mantenere, meno stati inconsistenti da debuggare.
Italy Soft
In 30 minuti di audit gratuito analizziamo i tuoi processi e calcoliamo il ROI concreto. Nessun impegno.