#7 ~ Chi abita sotto il cloud?
Disclaimer: due parole prima di iniziare.
Questa newsletter la scriviamo noi di Green Software Italia: non siamo una redazione, abbiamo tante voci e vogliamo che si sentano. Ogni articolo ha un suo tono, a volte anche un’idea che cozza con quella che leggerai nel pezzo dopo e per noi va bene così.
Quello che leggi qui è il pensiero di chi l’ha scritto, non la posizione ufficiale di nessuno. Qualcuno di noi, quando scrive, usa l’AI come strumento compensativo e lo diciamo perché ci sembra onesto: cerchiamo di farlo con la testa, sapendo che anche questi strumenti hanno un costo e che la cosa più preziosa, alla fine, resta avere qualcosa di vero da dire.
Buona lettura. 📖
Un servizio rallenta. Aumentiamo le risorse.
Lo spazio sta finendo. Estendiamo lo storage.
Sta arrivando un picco di traffico. Aggiungiamo istanze.
Il cloud ci permette di fare tutto questo in pochi minuti. È una possibilità preziosa: possiamo adattare l’infrastruttura senza acquistare ogni volta nuove macchine e senza dimensionare tutto sul peggior caso immaginabile.
Ma c’è un’abitudine sulla quale vale la pena fermarsi: quando ottenere capacità aggiuntiva diventa così semplice, è facile che sia la prima soluzione che prendiamo in considerazione. E che, passato il problema, quella capacità resti lì.
☁️ L’elasticità funziona anche al contrario
Pensiamo a un ambiente di test usato durante il giorno e lasciato attivo ogni notte. Oppure a una macchina sovradimensionata dopo un incidente, perché nessuno vuole rischiare di trovarsi di nuovo senza margine.
Sono situazioni comprensibili. La continuità del servizio conta, e ridurre risorse richiede verifiche. Nel frattempo, però, una decisione provvisoria può diventare una configurazione permanente.
Nei suoi Green Software Patterns, la Green Software Foundation invita ad adeguare le macchine virtuali al loro effettivo utilizzo. Il principio è sfruttare meglio le risorse fisiche, evitando di distribuire poco lavoro su capacità eccessiva.
La formazione GSF spiega anche perché: il consumo di una macchina non diminuisce necessariamente nella stessa proporzione del suo carico. Poco lavoro non significa automaticamente poco consumo.
Il cloud offre strumenti per aumentare e ridurre la capacità. Progettare e verificare entrambe le direzioni resta una parte del nostro lavoro.
⚡ Anche la regione fa parte dell’architettura
Quando scegliamo dove eseguire un servizio, consideriamo latenza, costi, disponibilità e vincoli sui dati. C’è un’altra caratteristica da includere: l’intensità carbonica dell’elettricità.
È alla base della carbon awareness descritta dalla GSF. Le emissioni associate a un kilowattora cambiano tra luoghi e momenti diversi, in funzione di come viene prodotta l’elettricità. Per le attività flessibili, possiamo valutare dove e quando eseguire il lavoro anche sulla base di questa informazione.
Immaginiamo un’elaborazione che deve essere pronta entro il mattino: se non serve avviarla a un minuto preciso, possiamo valutare quando eseguirla anche sulla base dell’intensità carbonica prevista.
È una possibilità da verificare con i vincoli reali del sistema. Spostare dati, cambiare regione o rinviare un’attività può introdurre costi e conseguenze che vanno considerate nel bilancio.
Il punto interessante è che il requisito “deve essere pronto entro le otto” lascia scelte diverse da “deve partire ogni notte a mezzanotte”.
A volte il margine per ridurre le emissioni nasce già da come definiamo il lavoro da fare.
📊 Sappiamo quanto costa. Quanto sappiamo dell’impatto?
Una fattura cloud ci permette di attribuire costi ai servizi. Per energia ed emissioni, ricostruire lo stesso dettaglio può essere più difficile.
La specifica Software Carbon Intensity della GSF considera l’elettricità consumata, la sua intensità carbonica e una quota delle emissioni legate al ciclo di vita dell’hardware. Le rapporta a un’unità utile del servizio, per esempio una transazione.
Questo approccio ci permette di valutare una modifica mantenendo chiaro che cosa il sistema deve produrre. Richiede però di dichiarare il perimetro e il metodo di calcolo. La stessa specifica riconosce la difficoltà di ottenere dati granulari nel cloud pubblico e invita a richiederli ai fornitori.
Anche Cloud Carbon Footprint, progetto open source nato in Thoughtworks, affronta questo problema: usa dati di utilizzo dei servizi e fattori di conversione per stimare energia ed emissioni. La metodologia esplicita che sono stime, con limiti di accuratezza.
Questi strumenti possono aiutarci a scegliere. Per usarli bene dobbiamo poter distinguere una misura da una stima e sapere che cosa comprende il numero che stiamo leggendo.
🌍 Le scelte locali fanno parte di una domanda più grande
Nel rapporto Key Questions on Energy and AI, l’Agenzia Internazionale dell’Energia stima che la domanda elettrica globale dei data center sia cresciuta del 17% nel 2025.
È un dato sull’insieme dei data center, non sul solo cloud pubblico. Non permette di attribuire una quota precisa al nostro servizio. Dà però la dimensione del sistema nel quale le nostre applicazioni funzionano.
Per questo mi interessa un green software capace di entrare nelle decisioni ordinarie: il dimensionamento di una macchina, la durata di un ambiente di test, la regione scelta per un servizio, l’orario di un’elaborazione.
Sono decisioni che prendiamo già. Possiamo includere l’energia e le emissioni tra gli elementi con cui le valutiamo, chiedendo dati migliori quando quelli disponibili non bastano.
Il cloud ci ha dato una grande libertà nel procurarci risorse. Vorrei che usassimo quella stessa libertà anche per rilasciarle quando non servono, utilizzarle meglio e capire le conseguenze delle nostre scelte.
L’elasticità diventa un vantaggio anche ambientale quando impariamo a usarla in entrambe le direzioni
Se guardaste oggi le risorse cloud che usate, cosa potreste spegnere, ridimensionare o far funzionare solo quando serve?
Se questo pensiero ti ha smosso qualcosa, scrivilo nei commenti: le voci servono, anche quelle in disaccordo.
Grazie di aver letto sin qui.
Il futuro digitale non arriva da solo. In buona parte lo programmiamo noi.
Chiara Corrado, co-founder di Green Software Italia
Fonti
- Green Software Foundation - Energy Efficiency e Match utilization requirements of virtual machines: proporzionalità energetica e dimensionamento delle risorse.
- Green Software Foundation - Carbon Awareness: intensità carbonica e flessibilità temporale e geografica delle elaborazioni.
- Green Software Foundation - Software Carbon Intensity Specification: metodo, perimetro, dati e unità funzionale per valutare le emissioni del software.
- Cloud Carbon Footprint - Methodology: stima dell’energia e delle emissioni a partire dall’utilizzo dei servizi cloud, con limiti dichiarati.
- International Energy Agency — Key Questions on Energy and AI, 2026: andamento della domanda elettrica dei data center.