Confronto serverless container: quando usare AWS Lambda, Azure Functions o Kubernetes. Guida pratica per architetti cloud.

Il problema che tutti i team affrontano (e che costa cari)

Nel 2023, un'azienda fintech italiana di medie dimensioni ha migrato 40 microservizi da VM tradizionali a container. Il risultato: costi operativi ridotti del 35%, ma anche 3 mesi di rallentamento nello sviluppo e un team di 6 persone dedicato full-time a Kubernetes. Sei mesi dopo, hanno riscritto metà di quei servizi in serverless. Morale della storia: non esiste una scelta giusta in assoluto — esiste la scelta giusta per il tuo contesto.

Questo articolo è una guida decisionale basata su 15 anni di implementazioni reali in ambienti enterprise. Se stai valutando un confronto serverless container per la tua architettura cloud, troverai criteri concreti, numeri reali e raccomandazioni che puoi applicare da lunedì.

Cosa intendiamo per serverless: oltre il nome marketing

Il termine serverless è tecnicamente impreciso — i server esistono sempre. Quello che cambia è il modello di responsabilità: con AWS Lambda, Azure Functions o Google Cloud Functions, non gestisci più l'infrastruttura sottostante. 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 brilla:

  • Carichi di lavoro event-driven: elaborazione di file su S3, code SQS, eventi di database. Un Lambda che risponde a un upload su S3 costa circa $0.0000002 per richiesta (al netto del tempo di esecuzione).
  • API con traffico intermittente: se la tua API riceve 10 richieste al giorno e poi 10.000 in un'ora, Lambda scala senza che tu faccia nulla. Con un container, dovresti prevedere capacity planning o pagare per istanze idle.
  • Prototipazione e MVP: un developer può pubblicare una funzione in 5 minuti senza toccare infrastruttura.
  • Elaborazione batch differita: job notturni, trasformazioni dati, thumbnail generation.

I limiti reali che i vendor non ti dicono:

  • Cold start: una Lambda Node.js impiega tipicamente 50-200ms per avviarsi, ma con VPC e runtime pesanti (Java, .NET Core) può arrivare a 3-5 secondi. Per applicazioni real-time, questo è inaccettabile.
  • Timeout massimo: AWS Lambda ha un limite di 15 minuti per esecuzione. Azure Functions arriva a 60 minuti con Premium Plan, ma il costo cambia drasticamente.
  • Peso delle immagini: il pacchetto di deploy per Lambda è limitato a 50MB compressi (250MB decompressi). Questo esclude molte librerie ML e runtime complessi.
  • Vendor lock-in: ogni provider ha il proprio modello di pricing e API. Migrate da Lambda a Azure Functions non è una semplice operazione di configurazione.

Container: il controllo che il serverless non offre

I container (Docker, containerd) sono unità di packaging standardizzate che includono l'applicazione e tutte le sue dipendenze. Non sono una tecnologia nuova — esistono dagli anni 2000 — ma la loro maturità nel cloud enterprise è esplosa con Kubernetes.

AWS ECS/EKS, Azure AKS, Google GKE offrono orchestrazione di container con SLA enterprise:

  • EKS (Elastic Kubernetes Service) parte da $0.10/ora per cluster management, più costi EC2 per i nodi worker.
  • AKS è gratuito per il management — paghi solo i nodi worker.
  • GKE offre Autopilot con pricing pay-per-pod, ideale per workload variabili.

Quando i container sono la scelta obbligata:

  • Performance deterministiche: con container hai sempre la stessa latenza di startup (millisecondi, non secondi). Per applicazioni di trading ad alta frequenza o API con SLA stringenti, questo è un requisito non negoziabile.
  • Runtime personalizzati: se hai bisogno di una versione specifica di Python con librerie native compilate, un container Ti dà il pieno controllo. Lambda supporta runtime predefiniti (Node.js 18, Python 3.11, Java 17, .NET 6) — e i custom runtime sono possibili ma complessi.
  • Stato persistente: un container può montare volumi persistenti (EBS, Azure Disk, PersistentVolumeClaims) e mantenere cache locali. Lambda è stateless by design.
  • Compliance e security: aziende finanziarie e sanitarie spesso richiedono audit trail completi dell'infrastruttura. Con container, ogni layer dell'immagine è tracciabile e firmabile (notarizzazione Docker, Sigstore).
  • Gestione team complessa: se hai 30 team che rilasciano servizi, Kubernetes Namespaces e RBAC (Role-Based Access Control) offrono governance che con Lambda è più difficile da implementare.

Confronto serverless container: i numeri che contano

Costo: la trappola dell'apparente risparmio

Il pricing serverless sembra irresistibile: paghi solo per quello che usi. Ma nei test che ho condotto su workload production reali, Lambda diventa più costoso dei container a partire da ~5 milioni di invocazioni mensili con durata media superiore ai 500ms.

Scenario concreto: un servizio di image processing che elabora 100.000 immagini/giorno, ognuna in 800ms, costa:

  • Lambda: ~$0.60/giorno (invocazioni) + $2.10/giorno (compute a $0.0000166667 per GB-second) = **$810/mese**
  • Container su ECS con istanze Reserved (1 anno): una t3.medium ($0.0416/ora) sempre accesa elabora tutto in 22 ore = **$12.50/giorno = ~$375/mese**

Per carichi prevedibili e sustained, i container vincono economicamente. Ma se il carico fosse variabile (100.000 un giorno, 10 il giorno dopo), Lambda resterebbe costante mentre le istanze container resterebbero pagate anche quando idle.

Latenza: cold start vs overhead di orchestrazione

Un benchmark che ho eseguito su AWS nel 2024 mostrava:

  • Lambda Node.js (nativa): 12ms media, 98° percentile 45ms (nessun cold start)
  • Lambda Python (nativa): 18ms media, 98° percentile 62ms
  • Lambda Java 17 (con JVM): 380ms media, 98° percentile 1.2s (cold start incluso)
  • Container ECS Fargate (1 vCPU, 2GB): 8-15 secondi per startup iniziale, ma poi 2-5ms per richiesta
  • Container su EC2 bare metal (m5.metal): 50-80ms overhead di rete verso load balancer

Conclusione: per latenza critica, i container su infrastruttura warm hanno vantaggio netto post-startup. Ma il cold start container può essere peggiore di Lambda per workload occasionali.

Scalabilità: chi gestisce meglio i picchi

  • Lambda: scaling automatico, 1000 esecuzioni parallele per default (richiedibile fino a decine di migliaia). Ideale per picchi imprevedibili.
  • Kubernetes HPA (Horizontal Pod Autoscaler): scala basata su CPU/memoria con delay di 30-60 secondi. KEDA (Kubernetes Event-driven Autoscaling) permette scaling su code eventi, avvicinandosi al modello serverless.
  • AWS ECS Service Auto Scaling: simile a K8s, con target tracking policies.
  • Azure Container Apps (ACA): serverless container experience su Kubernetes gestito. DAPR integrato, scaling a zero, cold start inferiori a 2 secondi.

Azure Container Apps è particolarmente interessante: offre i vantaggi dei container (runtime custom, persistenza, DAPR) con il billing serverless. Se vuoi container ma senza gestire cluster, è la scelta migliore su Azure.

Matrice di decisione: quando scegliere cosa

Scegli Serverless se:

  • Il tuo team è composto principalmente da sviluppatori, non DevOps
  • I carichi di lavoro sono event-driven o batch-oriented
  • Il traffico è fortemente variabile (90% idle, 10% spike)
  • Devi rilasciare MVP in meno di una settimana
  • L'operatività minima è un requisito (nessun on-call infrastruttura)
  • L'applicazione è stateless per natura
  • Usi altri servizi managed (DynamoDB, SQS, EventBridge)

Scegli Container se:

  • Hai bisogno di <50ms di latenza consistente
  • Il runtime è personalizzato (versioni specifiche, librerie native)
  • Hai statefulness o cache locale critica
  • Il team ha competenze Kubernetes/DevOps solide
  • La compliance richiede controllo completo dell'infrastruttura
  • Stai costruendo una piattaforma interna per più team
  • Il carico è sustained e prevedibile

Scegli Entrambi (architettura ibrida) se:

  • Hai un frontend API serverless (Lambda) che chiama microservizi containerized
  • Elaborazione eventi con Lambda, business logic critica su container
  • Stai migrando gradualmente un monolite — nuove feature in serverless, core su container

Errori comuni che ho visto in produzione

1. "Facciamo tutto serverless perché è più economico"

Ho assistito a riscritture costose di interi stack perché un CTO aveva letto un benchmark parziale. Il risultato: 3 microservizi con 50ms di timeout che chiamavano Lambda con cold start a 3 secondi. La soluzione corretta era tenere quei servizi containerizzati.

2. "Kubernetes è lo standard, migrate tutto"

Kubernetes è potente ma complesso. Un cluster EKS con 20 nodi, networking CNI, Ingress controller, cert-manager, e monitoring costa facilmente $800-1500/mese prima ancora di rilasciare codice. Per 5 microservizi con traffico modesto, è over-engineering puro.

3. Ignorare il vendor lock-in

Lambda usa VPC con subnet private e NAT Gateway. Spostare un'architettura event-driven da AWS a Azure richiede riscrivere integrationi (Event Grid vs EventBridge), reimplementare trigger S3, e ripensare interamente IAM. Questa è una decisione strategica, non tecnica.

4. Non considerare il costo del cold start

Se la tua Lambda risponde a 10.000 richieste/minuto, i cold start sono un problema di percentili. Ma se risponde a 10 richieste/minuto con business criticali (pagamenti, auth), un cold start di 2 secondi su ogni richiesta è inaccettabile. La soluzione: provisioned concurrency a $0.000015 per GB-second (Lambda Pricing), che annulla il risparmio serverless.

Raccomandazioni per settore e caso d'uso

Startup e MVP

Raccomandazione: serverless con AWS Lambda + API Gateway + DynamoDB.

Il team può rilasciare in giorni, non settimane. Il billing a zero per idle è cruciale per cash-flow early-stage. Esempio reale: un marketplace B2B ha lanciato MVP con 4 Lambda, Cognito, e DynamoDB per $12/mese di infrastruttura (esclusi data transfer).

Enterprise con compliance GDPR/SOX

Raccomandazione: container su AKS/GKE con politiche di rete strict e immutable infrastructure.

Il audit trail completo, il controllo delle versioni runtime, e la possibilità di air-gap sono requisiti normativi. Azure Government e AWS GovCloud offrono container con certificazioni FedRAMP che serverless non ha.

E-commerce con stagionalità

Raccomandazione: architettura ibrida — container per core checkout (bassa latenza, alta affidabilità), Lambda per raccomandazioni, notifiche, elaborazione ordini.

Durante Black Friday, il checkout deve reggere 100x traffico normale con SLA <200ms. Container con autoscaling predittivo (basato su trend storici) + provisioning anticipato risolve il problema. Le Lambda gestiscono i carichi burst che non giustificano capacity sempre accesa.

Machine Learning inference

Raccomandazione: container su EC2 (per latency-critical) o Lambda con container runtime (max 10GB).

AWS Lambda supporta ora container image fino a 10GB. Per modelli di ML che servono inferenza batch, questo è un game-changer: packi il modello in una container image, deployi su Lambda, e hai scaling automatico senza gestire GPU instances.

Conclusione: la domanda non è "cosa è migliore", ma "cosa è migliore per questo contesto"

Dopo 15 anni di architetture cloud, la lezione più importante è questa: le tecnologie non competono tra loro, complementano se stesse. Un'architettura cloud moderna raramente è 100% serverless o 100% container. È un ecosistema dove Lambda gestisce eventi, container eseguono logica stateful, e Kubernetes orchestra il tutto.

Il confronto serverless container che dovresti fare non è "chi vince", ma "dove ciascuno aggiunge il massimo valore nel mio caso specifico".

Azione immediata: se stai migrando, mappa i tuoi 10 servizi più critici su questa matrice. Quelli con traffico variabile >80% e latenza >500ms? Serverless. Quelli con costanti CPU-bound o requisiti di compliance? Container. Per il resto, mantieni flessibilità.

Articolo aggiornato a gennaio 2025. Per consulenze su architettura cloud per la tua azienda, visita Ciro Cloud.

Weekly cloud insights — free

Practical guides on cloud costs, security and strategy. No spam, ever.

Comments

Leave a comment