Migrare centinaia di app legacy su AWS senza bloccarsi

Partite da un inventario che mostri di che cosa ha davvero bisogno ogni app

Prima che qualcuno tocchi AWS, elencate ogni applicazione che gira sulle vecchie VM e annotate i dati che determinano lo sforzo di migrazione. All'inizio basta un foglio di calcolo condiviso. Ciò che conta è che ogni app abbia una riga, un responsabile e le stesse colonne.

Poi classificate ogni app in un piccolo numero di percorsi, per esempio aggiornamento, ricostruzione e dismissione. I team possono così pianificare per percorso invece di discutere ogni app partendo da zero.

• Versione del runtime e del framework, segnalando tutto ciò che è a fine vita
• Database, condivisioni di file e job pianificati da cui dipende l'app
• Integrazioni in entrata e in uscita, compresi hostname e indirizzi IP scritti nel codice
• Metodo di autenticazione ed eventuali segreti salvati sulla VM
• Responsabile di business, livello di utilizzo e finestra di fermo accettabile

Decidete se aggiornare o ricostruire app per app, non una volta per tutto il programma

Nessuna strategia unica va bene per centinaia di app. Ad alcune basta un aggiornamento del framework, una configurazione esternalizzata e un nuovo target di deploy. Altre contengono così tanto codice morto o una struttura così aggrovigliata che ricostruirle su una base pulita è più rapido che ripararle.

Decidete con criteri scritti, così team diversi arrivano alla stessa risposta. Una regola utile: se portare l'app sullo scheletro standard significa comunque riscrivere la maggior parte dei suoi controller e dell'accesso ai dati, ricostruitela. Se la logica di business si trasferisce quasi intatta, aggiornatela.

Il programma di Crédit Agricole, che ha spostato 600+ applicazioni interne da vecchie VM ad AWS, ha usato entrambe le strade. Le app sono state ricostruite sullo scheletro CodeIgniter interno della banca, alcune aggiornate e altre ricostruite da zero.

• Aggiornate quando il codice è leggibile, il suo comportamento è chiaro e il divario di versione del framework è piccolo
• Ricostruite quando la logica di business è mescolata ovunque alla presentazione o l'app dipende da funzionalità del linguaggio che sono state rimosse
• Dismettete quando l'utilizzo è quasi nullo e il responsabile di business è d'accordo, perché la migrazione più economica è quella che non si fa

Dividete il parco applicativo in blocchi e affidate ogni blocco a un solo team

A questa scala, un unico team centrale diventa il collo di bottiglia. Un modello a blocchi assegna un gruppo di app collegate a un piccolo team che ne è responsabile dall'analisi al cutover.

Raggruppate i blocchi per dipendenze comuni, non in ordine alfabetico. Le app che condividono un database o si chiamano a vicenda devono migrare insieme, altrimenti lo stesso lavoro di integrazione si ripete in più team.

I blocchi rendono anche misurabile l'avanzamento. Ogni team riporta gli stessi stati per ogni app, per esempio analizzata, migrata, testata, passata in produzione e dismessa, e il cruscotto del programma è la somma di questi stati. Il programma di Crédit Agricole funzionava così, e SDK Enterprises ha realizzato 50+ delle sue migrazioni di applicazioni come parte del team di programma.

Costruite uno scheletro standard e fateci approdare ogni app

Uno scheletro applicativo standard è ciò che trasforma centinaia di migrazioni in un processo ripetibile. Fissa le decisioni che non vanno riprese per ogni app: struttura delle directory, configurazione tramite variabili d'ambiente, formato dei log, health check, punti di aggancio per l'autenticazione e pipeline di deploy.

Ogni app migrata si distingue allora solo per la sua logica di business. Chi revisiona sa dove guardare, i team operativi ottengono log e allarmi coerenti, e una correzione allo scheletro arriva a tutte le app costruite su di esso.

Mantenete lo scheletro piccolo e versionato. Se cresce fino a diventare un framework a sé, i team cominceranno ad aggirarlo.

Pianificate cutover e rollback prima della prima migrazione

Ogni app ha bisogno di un piano di cutover che stabilisca come si sposta il traffico, come si spostano i dati e come si torna indietro. Decidetelo prima che si sposti la prima app. Improvvisare un rollback nel mezzo di un incidente è il modo in cui i programmi di migrazione perdono la fiducia del business.

• Finestra di congelamento: concordate con il responsabile di business quando si fermano le modifiche sulla vecchia VM
• Sincronizzazione dei dati: migrate i dati in anticipo, poi eseguite un'ultima sincronizzazione delle differenze durante la finestra di cutover
• Spostamento del traffico: cambiate il DNS o l'instradamento del load balancer, con TTL DNS bassi impostati giorni prima
• Smoke test: un breve controllo scriptato di login, schermate principali e integrazioni subito dopo lo spostamento
• Condizione di rollback: una persona indicata per nome e condizioni scritte per tornare indietro
• Vecchia VM conservata: spegnetela ma non cancellatela finché l'app non ha funzionato senza problemi su AWS per un periodo concordato

Scrivete runbook che qualsiasi team possa seguire dal primo giorno

Un runbook è la checklist di un'operazione ripetibile: preparare un'app, fare il cutover, tornare indietro con un rollback, dismettere la VM. Scrivete ciascun runbook una volta, testatelo sulle prime app e aggiornatelo ogni volta che qualcosa sorprende un team.

Un buon runbook indica comandi, responsabili e risultati attesi, non intenzioni. «Verificare che l'app funzioni» non è un passaggio. «Accedere con l'utente di test e confermare che la dashboard carichi i dati dell'account» lo è.

I runbook sono anche il modo in cui gli ingegneri che arrivano a programma avviato diventano produttivi in fretta. Uno specialista che arriva alla sesta settimana dovrebbe poter fare il cutover di un'app seguendo i documenti dopo una sola sessione in affiancamento.

Dove si inserisce un team esterno in una grande migrazione

I grandi programmi hanno spesso bisogno di capacità aggiuntiva per un periodo definito, senza cedere il controllo. Ci occupiamo di blocchi di migrazione all'interno di programmi più ampi, lavorando sullo scheletro, sui runbook e sugli strumenti del cliente, con i nostri ingegneri e specialisti freelance selezionati, sotto un unico contratto.

Domande frequenti