Quando la governance diventa intento
La chiamata che non ti aspetti
Due settimane dopo che Marco aveva scoperto il deployment conversazionale, non fu lui a chiamarci.
Fu il suo CFO.
«Ho bisogno di capire una cosa», disse Elena, senza preamboli.
«Stiamo pagando tre ambienti cloud. Vedo le fatture. Ma nessuno sa dirmi cosa stiamo davvero usando.»
Non era arrabbiata. Era confusa.
Domande semplici. Nessuna risposta.
Elena continuò, con calma:
«Nessuno è in grado di spiegarmi nel dettaglio se quelle 47 VM nel nostro cloud privato servono ancora tutte.»
«E perché la bolletta dell’hyperscaler è aumentata del 30% rispetto al trimestre scorso?»
«Ma è normale che per questi servizi arriviamo a spendere 12.000 euro al mese?»
Marco era in call con lei. Silenzio.
Non perché non gli importasse — ma perché effettivamente ogni piattaforma parlava una lingua diversa.
Modelli di costo diversi.
Applicazioni stratificate nel tempo da diversi team.
Tag diversi. Livelli di dettaglio diversi.
Ed era difficile sbrogliare il bandolo della matassa.
«Marco», disse Elena, «il deployment adesso funziona. Ma chi governa tutto questo?»
Il problema sotto il problema
Dopo la call, Marco ci scrisse.
«Elena ha ragione. Ho risolto come distribuire e gestire le nuove applicazioni in modo efficace. Ma non ho ancora una visione chiara di cosa, complessivamente, stia girando davvero.»
Sapeva perfettamente a cosa si riferisse Elena.
Un cloud privato basato su OpenStack, che ospita i workload core, stratificati nel tempo e gestiti da diversi team.
Un hyperscaler usato per elasticità e servizi dati, per garantire alta affidabilità.
Un ambiente VMware legacy tenuto in vita per quel sistema che nessuno osa toccare.
Tre ambienti. Tre dashboard. Tre modi diversi di descrivere la realtà.
«Non mi serve un altro pannello di controllo», disse Marco. «Mi serve qualcuno che mi dica cosa sta succedendo — e meglio se in un linguaggio “umano”.»
Quello che gli abbiamo mostrato
Marco tornò da noi con una domanda più concreta.
«Ma con la vostra piattaforma, potrei fare una domanda più semplice?» disse. «Quante macchine stanno davvero lavorando?»
Gli abbiamo allora fatto vedere la beta.
Scrisse direttamente:
«Quante VM hanno un utilizzo medio della CPU sotto il 60% negli ultimi 30 giorni?»
Otto secondi. La piattaforma correlò le metriche di osservabilità tra i diversi ambienti e rispose:
«31 macchine su 47 mostrano un utilizzo medio della CPU stabilmente sotto il 60%, 14 non hanno traffico di rete significativo da oltre 14 giorni. 9 non hanno un owner dichiarato.»
Marco non sembrò sorpreso. «Trentuno», disse. «La maggior parte.»
Quando perdi il legame tra decisioni e realtà
«So perché ho 47 macchine», disse Marco. « Le ho create nel tempo, man mano che i team applicativi rilasciavano nuove applicazioni. E ognuno mi chiedeva una VM”.
Fece una pausa.
«Ovviamente, quando ho potuto, ho ottimizzato, ma nel tempo quello che ho perso è il collegamento tra quelle decisioni — e ciò che oggi sta davvero girando.»
È qui che diventa necessario cambiare modalità di funzionamento. Non bisogna creare macchine ma spazio per workload applicativi.
E meglio ancora se puoi esprimerlo con un intento: di cosa ha bisogno un’applicazione per funzionare correttamente.
Ed è la piattaforma che decide come allocare l’infrastruttura per soddisfare quell’intento.
Le macchine sono un dettaglio implementativo — non una tua decisione.
Il risultato non è “meno risorse per disciplina”. È capacità allineata by design.
Non paghi macchine nel caso servano. Paghi ciò che viene effettivamente utilizzato.
Marco annuì.
«Se avessi deployato tutto così fin dall’inizio», disse, «molte di quelle macchine probabilmente non esisterebbero — o almeno non in quella forma.»
Esatto.
Dalla visibilità alla governance
Marco capì subito dove stavamo andando.
«Oggi mi date visibilità», disse. «Finalmente riesco a vedere le inefficienze.»
Si fermò. «Ma il passo successivo è fare qualcosa a riguardo, giusto?»
Sì. E non è un salto quantico — è un’estensione naturale di ciò che già esiste.
Perché funziona: un modello infrastrutturale vivo
Cloudsome non si basa su inventari statici o dashboard scollegate.
Mantiene un modello infrastrutturale vivo — una rappresentazione continuamente aggiornata di:
cosa esiste
come i componenti sono collegati
da cosa dipendono
come i sistemi si comportano realmente nei diversi ambienti
Metriche, log, relazioni e segnali di ownership confluiscono nello stesso modello.
Su questo modello gira un ciclo chiuso:
Discover — osservare cosa esiste e come si comporta
Decide — tradurre l’intento in azioni
Deploy — eseguire in modo deterministico
Observe — verificare i risultati tramite la telemetria
Govern — evidenziare le deviazioni e riconciliare la deriva
Oggi questo ciclo governa il deployment.
La realizzazione chiave è semplice.
La domanda «quante macchine sono sottoutilizzate?»
e l’intento «assicurati che nessuna macchina resti sottoutilizzata per più di 14 giorni»
sono la stessa cosa.
Una è una query. L’altra è una regola continua.
Cosa viene dopo — naturalmente
È esattamente in questa direzione che stiamo andando.
Ciò che oggi suona come: «Quante risorse non hanno un owner dichiarato?»
Diventa: «Avvisami quando una risorsa resta senza owner per più di 7 giorni.»
E, più avanti: «Non permettere la creazione di nuove risorse senza un owner e un budget dichiarato.»
Stessa lingua. Stesso modello. Stesso ciclo.
Solo applicato più in profondità.
Cosa disse Marco uscendo
«La complessità non è sparita», disse Marco. «Ma almeno adesso riesco a vederla.»
Poi aggiunse: «Quando potrò dire al sistema di agire su ciò che vede — non solo mostrarmelo — chiamami.» Ci siamo quasi.
——
Gli ambienti ibridi non devono diventare più piccoli.
Devono diventare comprensibili — e governabili — by design.
E quando il deployment parla per intenti,
la governance segue inevitabilmente.