Il serverless promette di eliminare la complessita della gestione infrastruttura: niente server, scala automatica, paghi solo per le esecuzioni effettive. Ma come tutte le soluzioni che promettono di eliminare complessita, la sposta altrove invece di eliminarla davvero. Capire quando il serverless e vantaggioso e quando e controproducente e una competenza chiave.

Dove il serverless funziona molto bene

Carichi irregolari e imprevedibili: se il tuo traffico va da 0 a 10.000 richieste e poi torna a 0, il serverless e ideale. Non paghi per idle time e scala automaticamente senza pre-provisioning.

Elaborazione asincrona e event-driven: processing di file uploadati, invio di email, notifiche, resize di immagini. Perfetto per l'architettura event-driven.

API con traffico variabile: backend di applicazioni mobile con picchi imprevedibili, webhook handler, API di integrazione.

Dove mostra i limiti

Latenza critica: il cold start puo essere di centinaia di millisecondi. Per API che richiedono latenze sotto i 100ms in modo costante non e adatto.

Stato e connessioni persistenti: le funzioni serverless sono stateless per design. Connessioni a database e sessioni persistenti richiedono soluzioni aggiuntive che aggiungono complessita.

Elaborazione lunga: AWS Lambda ha un timeout massimo di 15 minuti. Elaborazioni che richiedono ore non sono adatte.

Debugging: molto piu difficile che in un servizio tradizionale. Investire in tracing distribuito e logging strutturato e indispensabile.