Prima di firmare con un partner di migrazione cloud, chiedete come farà l'inventario di ciò che avete in esercizio, come sceglierà una strategia di migrazione per ogni applicazione, come progetterà e metterà in sicurezza l'ambiente di destinazione, come farà il rollback di ogni cutover, come vi mostrerà i costi e come preparerà il vostro team a gestire il risultato. Risposte precise e scritte vi dicono sulla migrazione che vi aspetta più di quanto dica la tariffa giornaliera.
Chiedete come scoprirà che cosa avete davvero in esercizio
Un piano di migrazione vale quanto l'inventario su cui si basa. Chiedete al partner come lo costruirà: con interviste ai responsabili delle applicazioni, dai dati dell'infrastruttura come le metriche dei server e le connessioni di rete, dal codice stesso, oppure da tutte e tre le fonti. La documentazione esistente è un punto di partenza, non una prova, perché col tempo si allontana da ciò che gira davvero.
Chiedete che cosa registrerà l'inventario e a chi apparterrà dopo. Una buona risposta elenca i campi e conferma che l'inventario resta a voi, qualunque cosa decidiate in seguito.
- Ogni applicazione, il suo responsabile di business e il suo livello di criticità
- Runtime, framework e sistemi operativi, segnalando tutto ciò che è a fine vita
- Database, condivisioni di file, job pianificati e code da cui dipende ogni applicazione
- Le integrazioni in entrambe le direzioni, comprese quelle che nessuno ha documentato
- Licenze legate all'hardware o al numero di processori, che potrebbero non valere nel cloud
- Il fermo accettabile e il calendario del business: chiusure di fine mese, picchi stagionali, scadenze normative
Aspettatevi una strategia per ogni applicazione, non una sola per tutto il parco
Le applicazioni passano al cloud in modi diversi. Le opzioni abituali sono spostare un'applicazione così com'è (lift and shift), portarla su una nuova piattaforma con piccole modifiche come un database gestito (replatform), rifattorizzarla per usare i servizi cloud, sostituirla con un prodotto software-as-a-service, lasciarla dov'è per ora oppure dismetterla. Un partner che propone lo stesso approccio per tutto non ha guardato abbastanza da vicino.
Chiedete i criteri che usa per scegliere, e chiedete di vederli applicati a tre o quattro delle vostre applicazioni prima di firmare. Il suo ragionamento sui vostri sistemi reali vi dice più di una slide sul metodo. Chiedete in particolare come tratta le applicazioni su runtime a fine vita, perché spostarle senza modifiche trasferisce i vecchi rischi sulla nuova piattaforma.
Scoprite chi progetta e mette in sicurezza la landing zone
La landing zone è l'ambiente di destinazione preparato in anticipo: struttura degli account, identità e accessi, rete, log, cifratura e le regole di protezione che ogni applicazione eredita. Un errore a questo livello si ripete in ogni applicazione che vi approda. Chiedete chi la progetta, se è definita come codice, per esempio con Terraform, e se il vostro team di sicurezza la revisiona prima che si sposti la prima applicazione.
La sicurezza nel cloud è condivisa. Il provider protegge l'infrastruttura sottostante, e voi restate responsabili di come la configurate e la usate. Chiedete al partner quali controlli imposterà, quali restano al vostro team, e come vengono concessi, registrati e poi revocati alla fine gli accessi dei suoi ingegneri.
- Account o progetti separati per ambiente, con la produzione isolata
- Single sign-on con utenti nominativi e ruoli con privilegi minimi, senza credenziali di amministratore condivise
- Log centralizzati e tracce di audit che gli ingegneri del progetto non possono disattivare
- Cifratura a riposo e in transito come impostazione predefinita, con i segreti tenuti fuori dal codice
- Regioni scelte per rispettare i vostri obblighi di localizzazione dei dati e il GDPR
Fatevi illustrare un cutover e un rollback
Il cutover è il momento in cui traffico e dati passano al nuovo ambiente, ed è lì che una migrazione è più visibile per il business. Chiedete al partner di illustrare passo per passo un cutover per una delle vostre applicazioni: come vengono sincronizzati i dati, come viene spostato il traffico, quali controlli si eseguono dopo e chi decide che ha funzionato.
Poi chiedete come tornerebbe indietro. Un piano credibile indica le condizioni che fanno scattare un rollback, la persona che prende la decisione e per quanto tempo il vecchio ambiente resta disponibile. Se dopo lo spostamento gli utenti hanno scritto dati nel nuovo ambiente, chiedete come questi dati tornano in quello vecchio. I piani deboli saltano questa domanda.
Il nostro articolo sulla migrazione di centinaia di app legacy su AWS mostra come questi passaggi diventano runbook su un grande parco applicativo.
Pretendete di vedere i costi prima che arrivi la prima fattura
I costi del cloud si comportano in modo diverso da quelli di un data center. Pagate ciò che è in funzione, compresi gli ambienti di test che nessuno ha spento, lo storage che continua a crescere e i dati trasferiti fuori dalla rete del provider. Chiedete una stima dei costi per applicazione con le ipotesi messe per iscritto, e chiedete come il partner la confronterà con l'uso reale nei primi mesi.
La visibilità sui costi è una scelta di progettazione, non un report mensile. Chiedete regole di tagging che colleghino ogni risorsa a un'applicazione e a un responsabile, budget e allarmi fin dal primo giorno, e una revisione delle dimensioni delle istanze quando le applicazioni hanno girato sotto carico reale. Dimensionare i server cloud come il vecchio hardware è un modo sicuro per pagare capacità che nessuno usa.
Segnali che una proposta di migrazione non è pronta
Ciascuno di questi segnali può avere una spiegazione. Diversi nella stessa proposta di solito significano che il rischio è stato lasciato a voi da scoprire.
- Una tempistica fissa prima che qualcuno abbia visto il vostro inventario
- Un'unica strategia di migrazione applicata a tutte le applicazioni
- Nessun piano di rollback scritto, oppure un rollback che dipende dal ripristino dei backup sotto pressione
- Account cloud, codice dell'infrastruttura o pipeline di proprietà del partner invece che vostri
- Stime dei costi senza ipotesi, e nessun piano per tag o budget
- Il trasferimento di conoscenze previsto nell'ultima settimana
Pianificate il trasferimento di conoscenze dalla prima settimana, non dall'ultima
La migrazione finisce; la gestione della piattaforma no. Chiedete come il vostro team imparerà a gestire ciò che viene costruito: lavoro in affiancamento su compiti reali durante la migrazione, runbook per le operazioni ricorrenti e una presentazione di monitoraggio e allarmi alle persone che saranno reperibili.
Chiedete che tutto stia nei vostri account e nei vostri repository fin dall'inizio: codice dell'infrastruttura, pipeline, runbook e diagrammi. Poi concordate come si accetta il passaggio di consegne, per esempio quando il vostro team esegue il deploy e il rollback di un'applicazione senza l'aiuto del partner.
Abbiamo lavorato nel team che ha spostato 600+ applicazioni interne di Crédit Agricole da vecchie VM ad AWS, realizzando direttamente 50+ di quelle migrazioni. Se volete un secondo parere su una proposta di migrazione, o un team che realizzi una parte del lavoro, i nostri ingegneri dell'infrastruttura cloud possono esaminare queste domande con voi.
Punti chiave
- Chiedete come verrà costruito e verificato l'inventario, perché ogni stima e ogni piano a ondate dipendono da esso.
- Aspettatevi una strategia di migrazione scelta applicazione per applicazione, con criteri che potete vedere applicati ai vostri sistemi.
- Fate definire la landing zone come codice, revisionare dal vostro team di sicurezza e conservare nei vostri account.
- Non accettate un piano di cutover senza una condizione di rollback esplicita e un modo per recuperare i dati scritti dopo lo spostamento.
- Concordate tagging, budget e modalità di accettazione del passaggio di consegne prima che si sposti la prima applicazione.
Domande frequenti
Il partner che valuta il nostro parco applicativo deve anche migrarlo?
Può farlo, e spesso si risparmia tempo, perché il team che ha costruito l'inventario conosce i casi particolari. Acquistate la valutazione come un deliverable separato di vostra proprietà, così potrete portarla a un altro partner se la proposta di migrazione non vi convince.
Come confrontare le proposte di diversi partner di migrazione?
Date a ogni partner lo stesso estratto dell'inventario e le stesse domande, e chiedete a ciascuno di applicare i propri criteri alle stesse poche applicazioni. Confrontate il ragionamento, i piani di rollback e le ipotesi alla base delle stime, non solo il prezzo totale.
Il nostro team può continuare a rilasciare funzionalità durante la migrazione?
Sì, se il piano spiega come. Concordate una finestra di congelamento delle modifiche per ogni applicazione, un modo per mantenere sincronizzati i due ambienti mentre si sposta, e chi approva i rilasci mentre un'applicazione è in fase di migrazione.