Casi svizzeri: serverless o container, scegli in base a RPS e durata

Scegli il serverless per carichi di lavoro brevi e guidati da eventi, i container per servizi di lunga durata, con stato o che richiedono molte risorse. I motivi principali sono il modo in cui ciascun modello scala, come viene fatturato e quanto controllo operativo ti resta: il serverless baratta controllo con comodità, i container barattano comodità con prestazioni prevedibili e portabilità.

---

In breve:

• I container sono la scelta migliore per carichi con traffico costante e prevedibile, grazie ai costi contenuti e a prestazioni prevedibili; il serverless si adatta meglio al traffico irregolare e guidato da eventi.

• L'autoscaling di Kubernetes reagisce lentamente alle metriche esterne, mentre le funzioni serverless scalano quasi istantaneamente: una differenza che pesa sulle applicazioni sensibili alla latenza.

• I carichi basati su container gestiscono connessioni con stato e sessioni di lunga durata molto più facilmente delle funzioni serverless, che per natura sono senza stato.

• Le differenze di costo sono rilevanti: con i container paghi la capacità riservata a prescindere dall'utilizzo, mentre il serverless fattura per richiesta e tempo di esecuzione, il che conviene ai carichi intermittenti.

• Competenze del team, prevedibilità del carico e requisiti di residenza dei dati sono fattori decisivi nella scelta dell'architettura, e nei sistemi in produzione gli schemi ibridi sono la norma.

---

Che cosa sono i container?

Un container racchiude un'applicazione e le sue dipendenze in un'unica immagine, costruita secondo il formato OCI (Open Container Initiative), così da funzionare allo stesso modo su un portatile, su un server di test o su un cluster di produzione. Sotto il cofano, i container si appoggiano ai namespace di Linux per l'isolamento e ai cgroup per limitare CPU e memoria: per questo più container possono condividere lo stesso host senza darsi fastidio.

Far girare un container è semplice. È quando ne fai girare centinaia in produzione che entra in gioco Kubernetes. Kubernetes assegna i container ai nodi, riavvia quelli che falliscono e usa l'Horizontal Pod Autoscaler per aggiungere o rimuovere repliche in base a CPU, memoria o metriche personalizzate, verificate a intervalli di sincronizzazione ricorrenti e non in tempo reale. Gestisce anche la service discovery, così i container si trovano a vicenda per nome, e gli aggiornamenti progressivi, così puoi rilasciare una nuova versione senza interruzioni.

Il ciclo di vita operativo attorno ai container è questo:

• Costruisci un'immagine e la pubblichi in un registry come parte della pipeline CI/CD.

• Distribuisci l'immagine su un cluster, dove Kubernetes la assegna ai nodi disponibili.

• Monitori e aggiorni i nodi sottostanti, perché sistema operativo e runtime restano responsabilità tua.

• Scali le repliche manualmente o automaticamente al variare del carico.

L'ultimo punto è il compromesso: ottieni il pieno controllo sull'ambiente di esecuzione, ma ti prendi anche tutta la manutenzione che ne deriva, dagli aggiornamenti dei nodi alle patch di sicurezza.

Che cos'è il serverless?

Il serverless, più precisamente function as a service (FaaS), ti permette di distribuire una singola funzione che viene eseguita in risposta a un evento: una richiesta HTTP, un messaggio in coda, il caricamento di un file. Non c'è nessun server da predisporre o aggiornare. La piattaforma avvia un ambiente di esecuzione, esegue il tuo codice e lo spegne quando il lavoro è finito.

La fatturazione segue la stessa logica. Invece di pagare un server sempre acceso, paghi le richieste e il tempo di esecuzione, di solito misurato al millisecondo, più la memoria che assegni. AWS Lambda è l'implementazione più diffusa di questo modello, e i suoi vincoli condizionano il modo in cui progetti attorno ad esso.

Meccanismi da conoscere prima di puntare sul serverless:

• Le funzioni hanno una durata massima di esecuzione e un tetto di memoria: i lavori lunghi o che consumano molta memoria richiedono un'architettura diversa.

• La concorrenza riservata garantisce a una funzione una quota di capacità, mentre la provisioned concurrency preinizializza gli ambienti per ridurre i cold start, con un costo aggiuntivo applicato per versione o alias.

• Le funzioni serverless di solito si appoggiano a servizi gestiti, come un gateway API o un database gestito, invece di ospitare quella logica al proprio interno.

• Il comportamento delle invocazioni cambia tra chiamate sincrone, che restituiscono direttamente una risposta, e asincrone, che possono riprovare o inoltrare gli errori a una dead-letter queue.

Questo modello dà il meglio quando il traffico è a picchi o imprevedibile, perché non paghi capacità inutilizzata tra un evento e l'altro.

Le differenze che determinano davvero la scelta

I due modelli divergono nettamente non appena vai oltre il discorso commerciale, e le differenze corrispondono a segnali del carico di lavoro che puoi misurare prima ancora di costruire qualcosa.

1. Comportamento dell'autoscaling. L'HPA di Kubernetes reagisce alle metriche a intervalli di sincronizzazione e scala le repliche entro i limiti che imposti, mentre strumenti come KEDA estendono il modello alle metriche esterne, per esempio la profondità di una coda, colmando buona parte del divario con l'elasticità delle funzioni. Le piattaforme serverless scalano per invocazione quasi istantaneamente: perfetto per il traffico a picchi, ma rinunci al controllo fine su quante istanze girano contemporaneamente.

2. Modello di costo e costi a sorpresa. Con i container paghi la capacità che riservi, usata o meno, mentre il serverless fattura per richiesta e durata: più economico per i carichi intermittenti, più caro per quelli costanti e ad alto volume. Su AWS Lambda la memoria assegnata fa crescere proporzionalmente la CPU, quindi aumentarla per accelerare una funzione lenta può gonfiare la fattura senza che te ne accorga, se il carico non era limitato dalla CPU fin dall'inizio.

3. Latenza e cold start. Un container già avviato risponde subito, mentre una funzione rimasta inattiva deve prima inizializzare un ambiente, aggiungendo latenza. La provisioned concurrency su Lambda e i pool di container preriscaldati risolvono entrambi il problema, al prezzo di pagare di nuovo capacità inutilizzata.

4. Gestione dello stato. I container possono mantenere in memoria lo stato di sessione o connessioni di lunga durata tra una richiesta e l'altra; le funzioni serverless sono pensate per essere senza stato e di norma spostano i dati di sessione su un archivio esterno: ecco perché i carichi con stato finiscono quasi sempre sui container.

5. Portabilità e dipendenza dal fornitore. Un'immagine container gira su qualsiasi runtime compatibile con OCI, e Kubernetes stesso è un'astrazione portabile tra cloud diversi. Le funzioni serverless sono scritte sulle API, sui formati di evento e sui limiti di un fornitore specifico: migrare verso un altro fornitore significa riscrivere, non semplicemente ridistribuire.

6. Strumenti e osservabilità. Le piattaforme a container dispongono di strumenti maturi di tracing e debug costruiti attorno a processi di lunga durata, mentre il debug nel serverless dipende molto di più dai log e dal tracing specifico della piattaforma, perché non puoi collegare un debugger a un ambiente che non esiste più una volta terminata l'invocazione.

Consiglio pratico: prima di scegliere un modello di scalabilità, metti alla prova la tua funzione o il tuo container sotto carico realistico e misura durata media, concorrenza di picco e uso della memoria. Questi tre numeri ti dicono molto di più di qualsiasi diagramma di architettura.

Dove i due modelli si sovrappongono e come i team li combinano

Container e serverless condividono le stesse fondamenta cloud-native: microservizi, distribuzioni immutabili e pipeline CI/CD che rilasciano unità di codice piccole e indipendenti. Nella pratica la separazione è meno netta che in teoria.

Uno schema ibrido ricorrente fa girare i servizi centrali, per esempio un'API o un backend con stato, in container su Kubernetes, mentre gestori di eventi, webhook e lavori pianificati girano come funzioni al loro fianco. Strumenti come KEDA e Knative sfumano ulteriormente il confine, permettendo ai container di scalare a zero e di comportarsi come funzioni quando il traffico sparisce, mentre gli approcci function-in-container impacchettano codice in stile FaaS come immagine container per garantirne la portabilità.

Quando scegliere l'uno o l'altro: scenari di carico ricorrenti

La scelta giusta emerge quasi da sé una volta che hai dato un nome al tipo di carico.

• API e servizi web con traffico costante e prevedibile di solito costano meno sui container, perché la fatturazione serverless per richiesta cresce in fretta su volumi continui.

• Worker in background e job batch che girano brevemente e in modo irregolare si sposano naturalmente con il serverless, perché eviti di pagare capacità di calcolo inutilizzata.

• L'inferenza ML su GPU richiede quasi sempre container, perché le piattaforme serverless raramente offrono accesso alle GPU e i lunghi tempi di caricamento dei modelli vanno in conflitto con i limiti di timeout delle funzioni.

• Pipeline guidate da eventi e codice di collegamento, come ridimensionare un'immagine dopo il caricamento o inoltrare un webhook, sono il caso d'uso serverless da manuale.

• Servizi ad alto throughput su larga scala premiano di norma i container sul piano dei costi, perché una funzione costantemente occupata costa più per unità di calcolo di un container che esegue lo stesso carico in continuo.

I dati dell'indagine CNCF’s State of Cloud Native Development confermano questo quadro: nel primo trimestre 2025 i container sono usati da circa il 61% degli sviluppatori backend, mentre il serverless si ferma attorno al 20%, e il rapporto osserva che l'uso del serverless è calato nel tempo, dato che carichi costanti e intensi come il machine learning risultano meno convenienti con la fatturazione per invocazione.

Come scegliere: una checklist pratica

Passa in rassegna questi punti prima di impegnarti su uno dei due modelli.

1. Mappa l'andamento del traffico: è costante, a picchi, oppure quasi sempre fermo con punte occasionali?

2. Stima richieste al secondo, tempo medio di esecuzione e concorrenza di picco sotto carico realistico.

3. Verifica se il carico deve mantenere uno stato o connessioni di lunga durata tra le richieste.

4. Chiarisci i requisiti di conformità o di residenza dei dati che potrebbero escludere certi servizi gestiti.

5. Valuta le competenze del tuo team: gestire container e Kubernetes richiede capacità diverse dal distribuire funzioni e collegare eventi.

6. Chiedi alla tua piattaforma o al tuo fornitore quali garanzie SLA offre, come si comporta sui cold start e come sarebbe davvero un percorso di uscita dalla loro piattaforma.

Sul fronte container, nel primo trimestre 2025 l'uso di Kubernetes si attesta attorno al 61% tra gli sviluppatori backend, contro circa il 20% del serverless, un divario che indica come i container restino l'opzione predefinita per la maggior parte dei backend in produzione, mentre il serverless mantiene una nicchia solida.

Segnali d'allarme davanti ai quali vale la pena fermarsi: dipendenza stretta da API proprietarie del fornitore senza alcuno strato di astrazione, cold start senza un piano di mitigazione per i percorsi sensibili alla latenza e un'osservabilità che si ferma ai log di base, senza tracing distribuito.

Note pratiche dalle revisioni di architettura

Le revisioni di architettura tendono a rivelare sempre lo stesso schema: i team puntano sul serverless perché sembra più semplice da avviare, poi sbattono contro un muro quando il traffico diventa costante o il carico richiede uno stato. Una revisione condotta da sviluppatori senior all'inizio, e non a metà del lavoro, è di solito ciò che intercetta il problema prima che diventi una riscrittura.

Per i team che gestiscono container in produzione, alcune pratiche ripagano sempre: GitOps per le distribuzioni, così lo stato del cluster corrisponde a una fonte di verità sotto controllo di versione, una strategia consapevole sulla provisioned concurrency invece di un ripensamento dell'ultimo momento, e pipeline CI/CD che costruiscono e analizzano le immagini prima che arrivino al cluster. Anche i requisiti di sovranità dei dati pesano sulla decisione più di quanto la maggior parte dei team si aspetti. Il Kubernetes Service di Swisscom ne è un esempio: è nato come alternativa conforme e indipendente dal fornitore rispetto ai Kubernetes gestiti dagli hyperscaler, e sostiene carichi di produzione su larga scala per organizzazioni che devono mantenere l'infrastruttura in Svizzera. Ampersand ha gestito configurazioni operative altrettanto impegnative, tra cui una piattaforma multisito che serve oltre 600 siti web da un unico sistema, dove la coerenza operativa contava più di qualsiasi singola scelta di scalabilità.

Come Ampersand aiuta i team a scegliere e costruire l'architettura giusta

Scegliere tra serverless e container raramente è una decisione una tantum: condiziona i costi e il carico di lavoro del tuo team per anni. Ampersand conduce revisioni di architettura con sviluppatori senior coinvolti fin dalla prima conversazione, così la raccomandazione che ricevi è legata al tuo traffico reale e alle competenze del tuo team, non a una risposta preconfezionata.

Se sai già di aver bisogno di uno sviluppo, che si tratti di una nuova piattaforma, di una migrazione da un sistema obsoleto o di uno strato di integrazione che collega container e servizi gestiti, Ampersand definisce il lavoro come progetto a perimetro fisso o come collaborazione continuativa. Per i team che vogliono far rivedere le scelte architetturali in modo continuo e non una volta sola, sono disponibili piani di supporto tecnico ricorrente. I dettagli aggiornati su pacchetti e prezzi si trovano nella pagina dei prezzi. Tutti i dettagli su pacchetti e prezzi sono nella pagina dei prezzi. Parti da una conversazione sul tuo carico di lavoro: l'architettura giusta diventa di solito evidente molto prima che venga scritta una riga di codice.

Fonti

• Horizontal Pod Autoscaler

• provisioned concurrency

• CNCF’s State of Cloud Native Development

Domande frequenti

Il serverless costa meno dei container?

Dipende dall'andamento del traffico: il serverless di solito conviene per carichi intermittenti o a picchi, perché paghi per richiesta e tempo di esecuzione, mentre i container convengono per traffico costante e ad alto volume, perché non paghi un sovrapprezzo per ogni invocazione. I dati dell'indagine CNCF mostrano che, nel complesso, i container restano l'opzione più diffusa tra gli sviluppatori backend.

Kubernetes può scalare come il serverless?

L'Horizontal Pod Autoscaler integrato in Kubernetes scala le repliche a intervalli di sincronizzazione usando CPU, memoria o metriche personalizzate: è più lento e meno granulare della scalabilità a livello di funzione. Strumenti come KEDA lo estendono per reagire a sorgenti di eventi esterne, per esempio la profondità di una coda, colmando buona parte del divario con l'elasticità del serverless e mantenendo i carichi nei container.

Come evito la dipendenza dal fornitore con il serverless?

Le funzioni serverless sono scritte sui formati di evento e sulle API di un fornitore specifico, quindi una portabilità completa è difficile, anche se puoi limitare l'esposizione tenendo la logica di business in librerie condivise, separate dal codice dell'handler. I container evitano in gran parte questo problema, perché un'immagine OCI gira su qualsiasi runtime compatibile, inclusa una piattaforma sovrana come il Kubernetes Service di Swisscom.

I cold start contano sempre nel serverless?

I cold start pesano soprattutto sulle richieste sensibili alla latenza rivolte agli utenti, molto meno sui lavori in background o sull'elaborazione asincrona, dove un breve ritardo è invisibile per chi usa il servizio. La provisioned concurrency riduce i cold start mantenendo gli ambienti di esecuzione preinizializzati, con un costo aggiuntivo proporzionale alla concorrenza che riservi.

Consigliati

• Die Mitte: oltre 600 siti web di un partito svizzero gestiti da un unico sistema.

• Arthouse Kinos: un nuovo sito e una biglietteria online per i cinema più iconici di Zurigo.

• Mikron: uno showroom su un portatile, per macchine troppo grandi da portare in fiera.

• Repa Immobiliare: un portafoglio immobiliare fuori dalla carta, con un software che non va mai online.