Il cloud a dieta: tagliamo i costi, spegniamo il progetto

Narratrice: Le voci di questa puntata sono sintetiche. È lunedì mattina. Il CTO apre la riunione con un obiettivo: ridurre la spesa cloud del trenta per cento entro il mese. Il Junior guarda lo schermo, poi il tavolo.

Junior Developer: Quale ambiente possiamo spegnere? Quello di prova? Quello che nessuno usa? C’è un elenco dei proprietari, o almeno un foglio con scritto «non toccare» in rosso?

Chief Technology Officer: Spegnere quello che non serve. Questa è la direzione: trasformare ogni costo in una scelta consapevole. Non abbiamo ancora l’elenco, ma abbiamo già l’obiettivo. È un ottimo punto di partenza.

Junior Developer: Certo. Però, per scegliere cosa non serve, dobbiamo sapere a cosa serve. Chi lo sa? Perché in questo momento abbiamo un obiettivo di spegnimento e nessun nome da spegnere.

Chief Technology Officer: Per questo avviamo una trasformazione del risparmio. Ogni risorsa dovrà dimostrare il proprio valore. Architect, puoi definire un modello di classificazione che renda il processo scalabile e replicabile?

Software Architect: Propongo di dividere le risorse per domini, definire criteri condivisi e istituire un comitato. Il comitato approva la classificazione; la classificazione guida la revisione. Così evitiamo decisioni isolate.

Senior Developer: Il comitato costa meno dei server? No, aspetta: prima bisogna sapere quali server. E per saperlo serve il comitato. Bene. Abbiamo appena creato un ambiente di prova per decidere se spegnere l’ambiente di prova.

Junior Developer: Ho trovato ambienti inattivi. Alcuni non hanno attività visibile da un po’. Ma non c’è un proprietario indicato. Senior, riconosci questi nomi? Posso chiedere prima di spegnerli?

Senior Developer: Questi li riconosco. Credo. Alcuni li avevo creati io, ma non ricordo se erano temporanei o temporanei nel senso aziendale: cioè senza data di rimozione e con un nome che non aiuta.

Commerciale: Il cliente ha già sentito parlare di ottimizzazione. Ho detto che stiamo lavorando sul risparmio, e la reazione è stata positiva. Possiamo presentare questa iniziativa come un risultato già molto concreto.

Junior Developer: Ma il risparmio non è ancora comparso. Per ora abbiamo parlato di ridurlo, classificato alcune risorse e trovato ambienti che forse sono nostri. In quale report risulta il risparmio?

Software Architect: Per identificarlo correttamente propongo una piattaforma di osservabilità dei consumi. Avremo una vista coerente delle risorse e potremo prendere decisioni basate sui dati.

Junior Developer: Per osservare i consumi dobbiamo aggiungere risorse. Quindi la piattaforma costa. E poi usa dati per aiutarci a capire dove spendere meno.

Software Architect: È un investimento circolare. Costa un po’ per scoprire dove non spendere. Il valore non è nel costo della piattaforma, ma nella qualità delle decisioni che ci permetterà di prendere sul costo della piattaforma.

Junior Developer: Se la piattaforma misura anche il proprio costo, quando scopre che costa troppo si spegne da sola? O serve un comitato per autorizzare il risparmio?

Chief Technology Officer: Bene. Nel frattempo procediamo con una risorsa che sembra inattiva. La classificazione la aggiorniamo dopo: l’importante è dimostrare che il processo sa generare un’azione. Junior, puoi spegnere l’ambiente di prova?

Senior Developer: Un momento. Quello è l’ambiente che uso per i test. E c’è anche la dimostrazione al cliente. L’avevo creato come soluzione temporanea, quando serviva, poi è diventato il posto in cui succede tutto—

Junior Developer: Quindi non è inattivo. Ha solo un nome che lo fa sembrare inattivo. Spegnerlo prima della dimostrazione sarebbe un test interessante, ma non credo sia quello che intendevamo misurare.

Chief Technology Officer: Riaccendiamolo. Prima però: il costo del riavvio rientra nel budget dei risparmi? Non vorrei che la fase di recupero compromettesse l’obiettivo di ridurre la spesa.

Senior Developer: Il costo di riaccenderlo c’è. Quello di lasciarlo spento, a quanto pare, lo scopriamo durante la dimostrazione. Posso rimetterlo in funzione, ma non prometto che la soluzione temporanea abbia conservato la sua temporaneità.

Software Architect: Per il modello di classificazione, dopo il riavvio lo segniamo come attivo. Se poi i test lo usano, aggiungiamo la categoria: attivo con motivazione.

Narratrice: Il team riaccende l’ambiente. I test ripartono e la dimostrazione si svolge. Il Commerciale entra nella riunione successiva con una proposta già pronta: raccontare l’interruzione come una prova di sostenibilità.

Commerciale: Il servizio ha funzionato anche senza un pezzo di infrastruttura. È una prova di resilienza, raccontata con trasparenza. Nel frattempo, se il report non mostra il risparmio, possiamo registrare la riunione sull’obiettivo come costo evitato.

Junior Developer: Come si misura il costo evitato di una riunione che abbiamo fatto per ridurre il costo di un ambiente che abbiamo spento e poi riacceso?

Commerciale: Possiamo indicare il valore dell’attività di allineamento. Non è una cifra precisa, ma è un valore. E il cliente apprezza quando un’iniziativa ha un nome chiaro e una presentazione leggibile.

Narratrice: A fine mese la spesa non è diminuita. Il progetto, invece, ha un nome, un comitato e una presentazione. Il CTO convoca il gruppo per celebrare il nuovo modello di efficienza.

Junior Developer: Nel report possiamo separare il costo del comitato da quello della piattaforma? Così sapremo almeno quale dei due ci ha aiutato a non risparmiare.

Chief Technology Officer: Abbiamo creato un percorso replicabile: ogni risorsa viene valutata, ogni decisione è condivisa e ogni risultato viene comunicato. Questo è il nostro nuovo modello di efficienza. Ottimo lavoro, team.

Junior Developer: E quando spegniamo l’ambiente che abbiamo rimesso in funzione?

Chief Technology Officer: Appena avremo misurato quanto costa lasciarlo acceso.