Serverless vs Container: Guida Completa con Confronto Costi e Prestazioni

Il Dilemma che Costa Migliaia di Euro al Mese alle Aziende Italiane

Un'azienda fintech romana con 50 dipendenti ha speso €180.000 in 18 mesi per mantenere un'infrastruttura Kubernetes sovradimensionata. I loro container lavoravano al 12% di capacità media. Quando sono migrati a serverless, i costi mensili sono scesi da €9.500 a €2.100. Non è un caso isolato.

Dall'altra parte, una scale-up milanese del fintech ha scelto Lambda per 40 microservizi, salvo poi riscrivere metà del codice in container dopo 8 mesi: cold start che causavano timeout sulle API di pagamento, limiti di 15 minuti per le esecuzioni, e costi che esplodevano con carichi sostenuti.

Il problema?** Entrambe le aziende hanno scelto prima, ragionato poi.

Questa guida ti dà un framework decisionale basato su 15 anni di implementazioni enterprise in ambiente cloud (AWS, Azure, GCP). Se stai valutando serverless vs container per la tua architettura, troverai criteri oggettivi, numeri reali e una checklist che puoi applicare da lunedì.

---

Cosa Significa Davvero Serverless (Spoiler: i Server Esistono Sempre)

Il termine serverless è marketing tecnicamente impreciso. I server esistono eccome — quello che cambia è il modello di responsabilità operativa.

Con AWS Lambda, Azure Functions o Google Cloud Functions, non gestisci più l'infrastruttura sottostante. Non provisioni istanze, non configuri OS, non applichi patch di sicurezza. La piattaforma gestisce tutto questo. Tu paghi per millisecondo di esecuzione effettiva, e la piattaforma scala automaticamente da zero a decine di migliaia di istanze in pochi secondi.

Quando il Serverless È la Scelta Giusta

Il modello serverless eccelle in scenari specifici:

• Carichi di lavoro event-driven: elaborazione di file su S3, code SQS/SNS, eventi di database. Un Lambda che risponde a un upload su S3 costa circa $0.0000002 per richiesta (escluso il tempo di esecuzione).
• API con traffico intermittente: se la tua API riceve 10 richieste al giorno e 10.000 in un'ora, Lambda scala automaticamente. Con container, dovresti prevedere capacity planning o pagare istanze idle.
• Prototipazione e MVP: un developer può pubblicare una funzione in 5 minuti senza toccare infrastruttura. Zero configurazione, zero manutenzione.
• Elaborazione batch differita: job notturni, trasformazioni dati, generazione thumbnail, ETL.
• Integrazioni cloud-native: connettori pre-costruiti per DynamoDB, SQS, EventBridge, Azure Event Hub.

I Limiti Reali che i Vendor Non Ti Evidenziano

• Cold start: una Lambda "fredda" può impiegare 100ms-3 secondi per rispondere alla prima invocazione. Per API ad alta frequenza, serve prezzolamento (Provisioned Concurrency su AWS).
• Timeout massimo: 15 minuti su Lambda (configurabile fino a 10 minuti). Non adatto per job lunghi.
• Dimensione pacchetto: 250MB compresso, 50MB decompresso. Non puoi includere runtime pesanti.
• Vendor lock-in: il codice è legato all'ecosistema.迁移 verso Azure Functions richiede riscrittura.
• Debug complesso: ambiente di esecuzione effimero, log distribuiti, testing locale imperfetto.

---

Container: Cos'è e Perché Restano Indispensabili nel 2024

I container (Docker, containerd) impacchettano applicazione e dipendenze in un'unità leggera, portabile e isolata. Kubernetes orchestra container su larga scala, gestendo deployment, scaling, self-healing e load balancing.

Nel 2024, i principali cloud provider offrono servizi Kubernetes gestiti:

Servizio	Provider	Regione Italia
EKS (Elastic Kubernetes Service)	AWS	eu-south-1 (Milano)
AKS (Azure Kubernetes Service)	Azure	Italy North (Milano)
GKE (Google Kubernetes Engine)	Google Cloud	europe-west8 (Milano)
OKE (Oracle Kubernetes Engine)	Oracle Cloud	eu-madrid-1

Quando i Container Sono la Scelta Vincente

• Applicazioni stateful: database, cache (Redis), code di messaggi con requisiti di persistenza.
• Requisiti di latenza costante: cold start zero, controllo completo sul runtime e sulle risorse.
• Microservizi complessi con comunicazione interna: mesh service (Istio, Linkerd), tracciamento distribuito, policy di rete dettagliate.
• Team con competenze DevOps consolidate: se il tuo team già gestisce Kubernetes, sfrutta l'investimento.
• Carichi di lavoro consistenti: quando sai che userai il 60-80% delle risorse 24/7, i container costano meno del serverless.

---

Confronto Diretto: Serverless vs Container su Costi, Prestazioni e Operazioni

Criterio	Serverless (Lambda/Functions)	Container (Kubernetes)
Costo base	Pay-per-invocation (~$0.20/milionc di richieste)	Costo fisso istanze (da ~€20/mese per nodo)
Costo scalabilità	Zero extra per scaling automatico	Scala nodi: €50-500+ in più per istanza
Latenza cold start	100ms - 3 secondi	Zero (container già avviati)
Timeout max esecuzione	15 minuti (Lambda)	Illimitato
Controllo runtime	Minimo (runtime predefinito)	Totale (immagine Docker custom)
Vendor lock-in	Alto (API proprietarie)	Basso (standard OCI)
Tempo di setup iniziale	5-30 minuti	1-4 settimane
Gestione infrastruttura	Zero (managed)	Significativa (anche con EKS/AKS/GKE)
Debug e testing	Complesso	Semplice (locale = produzione)
Stato (stateful)	Limitato (DynamoDB, S3 esterno)	Nativo (PersistentVolume)
Ideale per traffico	Intermittente, imprevedibile	Costante, prevedibile

Esempio Pratico: API REST con 100k Richieste/Giorno

Scenario A — Serverless (Lambda + API Gateway):

• 100.000 richieste/giorno × 30 giorni = 3 milioni di richieste/mese
• Costo API Gateway: ~$3.50/mese (3.5M req × $0.000001/req)
• Costo Lambda: ~$0.30/mese (assumendo 100ms medio, 3M × $0.00000001/req)
• Totale approssimativo: €3-4/mese

Scenario B — Container (EKS + 2 nodi t3.medium):

• 2 nodi t3.medium: €40/mese each = €80/mese
• Storage EBS, load balancer: €15-25/mese
• Totale approssimativo: €95-110/mese

Per questo caso, serverless costa 95% meno. Ma se il traffico sale a 10 milioni di richieste/giorno, serverless supera i container in costo (~$150/mese) mentre i container restano fissi.

---

Framework Decisionale in 5 Passaggi

Passo 1: Analizza il Tuo Pattern di Traffico

• Traffico sporadico o imprevedibile? → Serverless
• Traffico costante 24/7? → Container
• Mix di entrambi? → Architettura ibrida (container per core services, serverless per eventi)

Passo 2: Valuta i Requisiti Tecnici

Rispondi a queste domande:

1. Hai bisogno di esecuzioni > 15 minuti? → Container
2. L'applicazione è stateful (DB, cache locale)? → Container
3. Hai requisiti di latenza sub-100ms costante? → Container
4. Usi runtime non standard (Rust, Go personalizzato)? → Container
5. L'applicazione è event-driven (S3, SQS, eventi)? → Serverless

Passo 3: Calcola il Costo Reale (Non Solo il Compute)

Strumento consigliato: AWS TCO Calculator, Azure Pricing Calculator.

Includi:

• Costo compute (istanze o invocazioni)
• Storage (EBS, S3 per immagini container)
• Networking (data transfer, load balancer)
• Managed services (RDS, DynamoDB, Redis — servono in entrambi i modelli)
• Costo del team (DevOps vs developer time)

Passo 4: Valuta le Competenze del Team

Competenza dominante	Raccomandazione
Sviluppatori (poco DevOps)	Serverless (meno infrastruttura)
Team DevOps esperto	Container (controllo completo)
Misto	Kubernetes con operatori serverless (Knative, AWS Fargate)

Passo 5: Pianifica per l'Ibrido

Le architetture cloud moderne raramente scelgono un estremo. Pattern emergenti:

• EKS + Fargate (AWS): container senza gestione nodi
• AKS + Container Apps (Azure): serverless containers
• GKE + Cloud Run (GCP): container serverless

Questi approcci ibridi combinano i vantaggi di entrambi i modelli.

---

Casi d'Uso Specifici: Quando Ogni Tecnologia Vince

Caso 1: Elaborazione File e ETL

Scelta: Serverless

Una pipeline ETL che elabora 50.000 file/giorno da S3:

• Lambda/SQS: costo ~€8/mese
• Kubernetes con job scheduler: costo ~€120/mese (nodi sempre accesi)

Architettura consigliata: S3 Trigger → SQS Queue → Lambda (o Azure Functions con Blob Trigger).

Caso 2: Applicationi Mobile Backend con API Complesse

Scelta: Container

Un backend per app mobile con autenticazione JWT, database PostgreSQL, caching Redis, e API GraphQL:

• Richiede connessioni persistenti al DB
• GraphQL resolvers complessi con timeout variabili
• Redis caching locale per performance

Architettura consigliata: Kubernetes (EKS/AKS) + RDS + ElastiCache (Redis) + Application Load Balancer.

Caso 3: Elaborazione Pagamenti (High-Stakes, Low-Latency)

Scelta: Container (con possibilità di Serverless per componenti specifici)

I pagamenti richiedono:

• Latenza prevedibile < 50ms
• Timeout configurabili > 15 minuti
• Logging e audit trail dettagliato
• Controllo completo sulla sicurezza (PCI-DSS)

Architettura: Kubernetes con auto-scaling basato su metriche custom, istanze C5/M5 per compute ottimizzato, service mesh per observability.

Caso 4: Job di Machine Learning Batch

Scelta: Ibrido

• Training model: Kubernetes (job lunghi, GPU, alta intensità)
• Inferenza leggera: Serverless (Lambda con hasta 10GB RAM, SageMaker Endpoints)
• Preprocessing dati: Lambda o Azure Functions con trigger eventi

---

Errori Comuni da Evitare nel 2024

Errore 1: Scegliere Serverless per "Risparmiare"

Se hai 10 milioni di richieste/giorno con pattern prevedibile, i container costano meno. Serverless diventa economico con traffico intermittente, non con volumi elevati.

Errore 2: Kubernetes per Principianti

EKS/AKS/GKE richiedono competenze significative. Un team senza esperienza Kubernetes impiegherà 3-6 mesi per essere produttivo. Per MVP o prototipi, inizia con ECS/Fargate, Azure Container Apps, o Cloud Run.

Errore 3: Ignorare il Vendor Lock-in

Lambda e Azure Functions usano runtime e API proprietari. Se prevedi di migrare cloud provider, preferisci container (standard OCI) o framework serverless portabili come OpenFaaS, Knative, o Apache OpenWhisk.

Errore 4: Non Pianificare l'Observability

Serverless distribuisce l'esecuzione su migliaia di istanze. Senza strumenti come AWS X-Ray, Azure Application Insights, o Datadog, il debug diventa quasi impossibile.

---

Checklist Pratica: Quale Tecnologia Scegliere

Scegli Serverless se:

• Il traffico è intermittente o imprevedibile
• I tuoi sviluppatori sono focalizzati sul codice, non sull'infrastruttura
• L'applicazione è event-driven (file upload, code triggered, webhook)
• Non hai requisiti di timeout > 15 minuti
• Puoi accettare cold start variabili (o hai budget per Provisioned Concurrency)
• Stai costruendo un MVP o prototipando

Scegli Container se:

• Il traffico è costante e prevedibile
• Hai bisogno di latenza costante e bassa (< 50ms)
• L'applicazione è stateful o richiede persistenza locale
• Usi runtime non standard o immagini custom pesanti
• Il team ha competenze Kubernetes/DevOps consolidate
• Hai requisiti di compliance che richiedono controllo completo sull'infrastruttura

Scegli Architettura Ibrida se:

• Hai mix di carichi di lavoro (batch + API real-time)
• Vuoi ottimizzare costi e performance per diversi scenari
• Stai migrando da legacy e vuoi approccio incrementale

---

Prossimi Passi per la Tua Architettura Cloud

1. Audit attuale: quantifica traffico, pattern di utilizzo, costi mensili. Strumenti: AWS Cost Explorer, Azure Cost Management, GCP Billing
2. Proof of concept: implementa un servizio pilota in entrambi i modelli, confronta costi reali dopo 30 giorni
3. Formazione team: investire in certificazioni (AWS Solutions Architect, CKA, Azure Administrator) si ripaga in mesi
4. Pianifica il monitoraggio: implementa observability prima della produzione, non dopo
5. Start small: non rifattorizzare tutto. Migra un servizio alla volta, misura, itera

Non esiste una scelta universalmente corretta. La tecnologia giusta è quella che risolve il tuo problema specifico, si adatta alle competenze del tuo team, e ottimizza i costi per il tuo pattern di utilizzo reale — non quello teorico.

Se hai bisogno di una valutazione personalizzata per la tua architettura cloud, contatta il team Ciro Cloud per un assessment gratuito.