La migrazione in cloud: il server che nessuno può spegnere

Narratore: Attenzione: questa puntata è prodotta con voci sintetiche. È lunedì mattina. Il team è in call, perché il CTO ha convocato una riunione straordinaria. Nel calendario, l'evento si chiama: Trasformazione.

Junior Developer: Il CTO ha condiviso lo schermo. C'è solo una slide. Una parola: cloud. Sotto, una freccia che punta verso l'alto.

Senior Developer: Segnala che è un messaggio dal board. Non una presentazione, un messaggio.

Junior Developer: Leggo: la direzione ha deciso. Entro fine anno tutti i sistemi vanno in cloud. Seguita da... trasformazione, opportunità, agilità, e tre puntini di sospensione.

Senior Developer: I tre puntini sono la parte più seria del messaggio.

Junior Developer: Domanda semplice: dove trovo l'elenco dei sistemi da migrare? Perché per pianificare mi serve una lista.

Senior Developer: Nella call precedente la stessa domanda l'ha fatta il Commercialo, per i preventivi. Gli hanno risposto che il preventivo si farà vendendo. Qui funziona uguale, solo che invece dei soldi ci sono le macchine.

Narratore: Il CTO risponde in chat, a tutta la call. L'elenco dei sistemi è l'inventario. E l'inventario si farà migrando.

Junior Developer: Quindi la roadmap la scriviamo mentre la eseguiamo. Non è nemmeno il percorso più corto, è l'unico. Il problema è che un inventario è esattamente il tipo di cosa che si fa prima di migrare, non durante. Vabbè. Segno inventario tra i deliverable.

Narratore: Poco dopo, Junior e Senior davanti alla console di gestione dell'infrastruttura.

Senior Developer: Ecco la realtà. Scrolla. Scrolla ancora. C'è ancora. Macchine con oltre dieci anni. E guarda: un terzo risulta spento da anni. Nessuno le ha mai eliminate. Si toccano dopo.

Junior Developer: E l'owner di ciascuna? Per migrare devo sapere a chi chiedere.

Senior Developer: La mappa degli owner esisteva. Un foglio condiviso. Con un solo nome. Una persona uscita tre anni fa.

Junior Developer: Tre anni fa. Quindi per ogni macchina posso scrivere owner: ignoto, e qualcuno lo approverà senza domande. Metà di questa console è un cimitero di macchine orfane, e entro dicembre dovremmo averle migrate tutte.

Senior Developer: Non tutte. Le spente da anni le lasciamo dove sono. Migrare una macchina spenta è più pericoloso che tenerla spenta.

Junior Developer: Aspetta. Qui, questo server fisico. È collegato al sistema principale. Si può spegnere per la migrazione?

Senior Developer: Non si sa. Ci girano tre servizi. E probabilmente qualcos'altro. Che nessuno ha mai identificato.

Junior Developer: Ma il qualcos'altro si può scoprire, no? Basta spegnerlo e vedere cosa smette di funzionare.

Senior Developer: Teoricamente sì. Solo che se smette di funzionare qualcosa di importante, la migrazione si chiama incidente. E diventa un'altra riunione.

Junior Developer: Ok, ma a un certo punto qualcuno dovrà decidere. Prima o poi quel server lo dobbiamo toccare. O almeno nominarlo in una slide, con un riquadro rosso e una freccia.

Narratore: Mercoledì arriva il Software Architect, convocato per definire l'architettura target. Fino a quel momento la migrazione riguardava un solo server.

Software Architect: Prima di migrare, va disaccoppiato tutto. Analisi dei domini, confini, eventi asincroni, contratti espliciti. Diciamo due anni di roadmap. Ma un'evoluzione reale.

Narratore: Alla call si aggiunge il CTO, che ha letto solo il titolo della roadmap. Il CTO accorcia: serve un risultato dimostrabile entro il prossimo trimestre, per la relazione al board. Due anni non entrano in una slide.

Junior Developer: Posso chiedere come si dimostra in un trimestre che una roadmap di due anni funziona?

Senior Developer: Si dimostra con una presentazione. Presentiamo la roadmap. In cloud, ovviamente. Che dimostra anche che il cloud funziona.

Software Architect: Perfetto. Riformulo. Stesso piano, stessa architettura target: due anni di roadmap, ma in milestone trimestrali. Il primo risultato dimostrabile sarà... dimostrare che la roadmap funziona.

Senior Developer: Oppure, e dico oppure. Facciamo una macchina virtuale che replica il server fisico. La spostiamo in cloud così com'è. Un primo passo. Pragmatico.

Junior Developer: Ma così in cloud ci finisce il legacy. Letteralmente. Il legacy, nel cloud. È la stessa cosa con un'altra location.

Narratore: Il CTO, in chat, definisce la proposta un primo passo pragmatico del percorso di trasformazione. Nessuno sa se fosse un complimento.

Software Architect: Tecnicamente è un lift and shift, e come primo passo di un percorso evolutivo è difendibile. Documento tutto come fase transitoria dell'architettura target.

Senior Developer: Fase transitoria. Parola elegante. Nel 2016 ho scritto soluzione temporanea in un commento del codice. È ancora lì, con tanto di promessa di refactoring.

Narratore: Nessuno obietta. Il commento nel codice, comunque, esiste davvero.

Senior Developer: E il foglio con gli owner, quello lo riusiamo pure noi. Copio la riga della persona uscita e la incoll sotto ogni macchina. Così l'inventario risulta completo, e completo è quello che conta nella relazione.

Junior Developer: Se è temporaneo, quando lo togliamo? Il server fisico, dico. Quando lo spegniamo davvero?

Senior Developer: Ci vediamo tra due anni. Se va bene.

Narratore: Due mesi dopo. La migrazione viene celebrata in una comunicazione aziendale come completata. Con tanto di grafico a torta.

Junior Developer: Leggo la comunicazione.Trasformazione completata, oltre novanta per cento dei sistemi ora in cloud. E c'è il mio sistema principale nella lista.

Senior Developer: È vero. In cloud gira una copia identica del server del 2013. Stessa configurazione, stessi dischi, stesso tutto.

Junior Developer: Aspetta. Quindi il novanta per cento comprende sistemi che in realtà sono lo stesso sistema, contato due volte? Uno in cloud e uno nella sala server?

Software Architect: Dal punto di vista dell'inventario, sono due asset distinti. Uno fisico, uno virtuale. Il dato è tecnicamente corretto. La comunicazione dice oltre novanta per cento in cloud, e la macchina in cloud c'è.

Junior Developer: E quello fisico? Il server originale. Dove sta ora?

Senior Developer: Nella sala server. Acceso. Collegato via VPN. Risulta ancora più affidabile della copia.

Junior Developer: Quindi... in realtà non è spento. La migrazione è completata, ma il server è acceso.

Senior Developer: La migrazione è completata. Lo spegnimento è un'altra iniziativa. Che verrà valutata nel prossimo ciclo.

Narratore: Il prossimo ciclo, infatti, esiste già nel vocabolario aziendale. È il luogo dove finiscono tutte le cose che nessuno ha intenzione di fare.

Software Architect: Precisamente. Lo spegnimento del server fisico rientra perfettamente nel dominio della decommissioning strategy. È già previsto nella roadmap. Del resto, i due anni dovevano pur cominciare da qualche parte.

Junior Developer: E nessuno ha il coraggio di spegnerlo.

Narratore: Il server fisico resta acceso. La comunicazione aziendale, invece, è perfettamente statica e non richiede manutenzione.