Ambiente AWS da dismettere, direzione già tracciata verso un'altra piattaforma cloud, decisione più o meno presa. Il classico scenario in cui si entra per "accompagnare" un passaggio che, sulla carta, è già stato deciso.

Poi però emerge una frase, detta quasi di lato, che cambia completamente il perimetro del lavoro:

Stiamo pagando AWS, ma non sappiamo esattamente per cosa.

Non "troppo". Non "poco". Proprio non spiegabile.

Ordinaria amministrazione in contesti in cui qualcuno, in solitaria, mette in piedi degli ambienti, non perde tempo a documentare nulla di quello che fa e lascia l'azienda in balia di se stessa.

E quando un costo non è spiegabile, non è un problema di cloud. È un problema di architettura.

L’attenzione cade abbastanza in fretta su S3. Non perché fosse l’unico servizio coinvolto, ma perché era quello che continuava a restituire una sensazione strana:

• consumo stabile
• nessun evento evidente
• nessuna crescita applicativa che lo giustificasse davvero.

Scavando, viene fuori una configurazione molto comune: bucket con versioning attivo, cancellazioni gestite a livello applicativo, policy di lifecycle incompleta.

I file "sparivano" per chi usava il sistema, ma continuavano a vivere tranquillamente nello storage sotto forma di versioni precedenti.

Il risultato era paradossale solo in apparenza: si stava pagando per dati che, dal punto di vista dell’applicazione, non esistevano più.

A rendere il quadro più opaco c’era anche una scelta perfettamente legittima, ma poco fortunata nel contesto: la regione.

Lo storage era collocato su Milano, regione che al momento dell'assesssment non offriva strumenti adeguati come S3 Storage Lens. Meno visibilità, meno strumenti nativi per capire cosa stesse crescendo, meno possibilità di raccontare quei costi in modo chiaro a chi li doveva approvare.

A quel punto è diventato evidente che la migrazione non c'entrava nulla. O meglio: c’entrava troppo poco per essere la prima cosa da fare.

Portarsi dietro quello storage, così com’era, avrebbe significato spostare il problema, non risolverlo. Cambiare cloud non avrebbe magicamente trasformato dati non governati in dati ordinati. Avrebbe solo reso il debito meno familiare, ma identico nella sostanza.

Il web è pieno di persone che si lamentano dei "costi improbabili di AWS (o piattaforme cloud in generale)" anche dopo aver spento tutti i servizi.

La decisione reale, quindi, non è stata "come migriamo", ma se aveva senso migrare senza prima rimettere sotto controllo lo storage. Rendere osservabile ciò che fino a quel momento non lo era. Capire quanto spazio fosse realmente vivo, quanto fosse solo inerzia tecnica, quanta parte di quel costo fosse una conseguenza diretta di decisioni prese anni prima e mai più riviste.

È uno di quei casi in cui il cloud non è caro, né sbagliato. È semplicemente non governato.

E quando manca una governance del dato, ogni euro speso diventa difficile da difendere, prima ancora che da ottimizzare.

Questo tipo di situazione ritorna spesso:

• versioning attivato "per sicurezza"; ottima idea
• cancellazioni delegate all’applicazione; comprensibile
• nessuno che si prenda carico del ciclo di vita completo; disastro garantito.

Finché i costi sono bassi non se ne parla. Quando iniziano a pesare, però, manca il linguaggio per spiegarli.

Ed è lì che, prima di qualsiasi migrazione, serve fermarsi e decidere.

Se vuoi parlarne, parliamone. Ti dico se serve davvero cambiare strada, o se è sufficiente sistemare quella su cui stai già camminando.