Cos'è lo scale to zero?

Lo scale to zero è il comportamento di un servizio cloud che, quando smette di ricevere richieste, spegne anche l'ultima istanza rimasta accesa (l'ultima copia del servizio in esecuzione) e smette di consumare calcolo, e di farlo pagare. Alla richiesta successiva il servizio ne riaccende una, e quella prima risposta arriva più tardi: è l'avvio a freddo, o cold start, il tempo che serve a preparare l'ambiente prima di eseguire il codice. Google usa il termine nella documentazione di Cloud Run, che in italiano dice scalabilità fino a zero. Le funzioni lo fanno per costruzione (lo spiega la voce su FaaS), ma oggi è un'impostazione che si accende o si spegne su servizi diversi: container, database, modelli di AI su GPU. Il compromesso resta lo stesso: azzerare il calcolo pagato nelle ore vuote in cambio di un'attesa sulla prima richiesta dopo il silenzio.

Leggi anche: FaaS · Funzioni che girano solo quando un evento le chiama: niente server da gestire, paghi solo ogni esecuzione.

Non solo funzioni: container, database e GPU

Sui container lo offrono Cloud Run e Azure Container Apps, dove il numero minimo di repliche è zero per impostazione predefinita e Microsoft precisa che a zero non si pagano costi di utilizzo; su Kubernetes lo aggiungono i progetti open source Knative e KEDA. Tra i database, Aurora Serverless v2 da novembre 2024 può scendere a zero unità di capacità: si mette in pausa quando non ha connessioni e di solito riprende in circa 15 secondi, mentre lo storage resta a pagamento. Neon di norma sospende il calcolo dopo 5 minuti di inattività e lo riattiva in poche centinaia di millisecondi. Sulle GPU che eseguono l'inferenza dei modelli i tempi cambiano scala: Hugging Face Inference Endpoints spegne l'endpoint, di norma, dopo un'ora di inattività, ma riaccenderlo può richiedere qualche minuto e la sua stessa documentazione sconsiglia di ripartire da zero se l'applicazione deve rispondere subito.

Cosa lo tiene sveglio senza che nessuno se ne accorga

A decidere lo spegnimento è il traffico, non il processore: Cloud Run guarda se l'istanza sta servendo una richiesta, Aurora guarda le connessioni aperte. Un pool di connessioni, i collegamenti al database che l'applicazione tiene aperti per riusarli, impedisce la pausa: AWS scrive che con RDS Proxy le istanze Aurora non vanno mai in pausa da sole, e che basta un tentativo di accesso con credenziali sbagliate per risvegliarle. Un controllo di disponibilità esterno che interroga il servizio ogni minuto gli manda, per definizione, una richiesta al minuto. E un numero minimo di istanze maggiore di zero esclude lo spegnimento per scelta.

Un esempio enterprise

Un'azienda manifatturiera ha molti servizi in cloud: il portale delle note spese, gli ambienti di collaudo dei team, un modello su GPU che classifica i documenti dei fornitori qualche volta al giorno, un database di sviluppo e l'area clienti per gli ordini. Lo scale to zero su collaudo e sviluppo toglie dalla fattura notti e fine settimana, ma solo una volta spenti il monitoraggio che interrogava il database ogni minuto e il pool che lo teneva sveglio. Il classificatore scende a zero perché nessuno ne aspetta il risultato sul momento. All'area clienti resta invece un'istanza sempre accesa: qualche secondo di attesa davanti a un cliente costa più di quella macchina.

Perché conta per chi decide

Non pagare le ore vuote ha un prezzo, l'attesa sulla prima richiesta: da qualche centinaio di millisecondi a qualche minuto, secondo cosa va riacceso. La domanda è chi aspetta: se è un processo notturno o un collega, lo zero conviene; se è un cliente o un impegno contrattuale sui tempi di risposta, un'istanza minima sempre accesa è un costo fisso e noto in anticipo. Poi, con la disciplina FinOps, va verificato in fattura che le ore vuote siano a zero: dove si pagano le ore di accensione (database, endpoint GPU), un servizio tenuto sveglio da un controllo dimenticato costa come uno sempre acceso. Lo stesso profilo di carico pesa nella scelta tra serverless, on-prem ed edge.