Nei processi di trasformazione digitale, necessari alle aziende per esprimere il proprio effettivo potenziale sul mercato, la migrazione del data center (DC), in uno scenario multicloud, è tra i percorsi più delicati ma strategici che è necessario sostenere.

Si tratta di ridistribuire o trasferire completamente in un nuovo ambiente DC l’ambiente esistente. Parliamo quindi di un processo completo, critico (e in alcuni casi vitale alla sopravvivenza del business) che prevede una pianificazione sistematica della migrazione. 

Oggi quando si parla di migrazione del data center ci si riferisce spesso all’adozione di piattaforme cloud e di risorse data center gestite. E sempre di più si parla della capacità di scegliere soluzioni multicloud in grado di sposare effettivamente le esigenze aziendali, a seconda della tipologia dei carichi applicativi.

Questo è tra gli aspetti più importanti. I test di migrazione devono garantire, prima dell’effettivo “passaggio” che riposizionamento e gestione della pianificazione dei flussi di lavoro applicativi abbiano un impatto minimo sulle operazioni correnti.

Migrazione DC, uno scenario? Tanti scenari

Lo scenario non è univoco. I dati prevedono una crescita dei ricavi per i provider di cloud pubblico che passano da 180 miliardi di dollari nel 2018 a 277 miliardi nel 2021. Non si discute sul fatto che l’adozione di cloud pubblici e privati e l’hosting di colocation, stiano crescendo a tassi enormi, ma è certo che lo scenario è decisamente variegato e che il cloud pubblico rappresenta, proprio in un’ottica multicloud, solo una prospettiva.

In Italia si stimano investimenti per la DC migration al 20%, siamo già oggi il quarto Paese in Europa, quando si parla di cloud. Un’analisi convincente di NetConsulting cube ci porta a sostenere che non tutti i carichi di lavoro siano pensati per il cloud pubblico.

Ci sono investimenti in hardware IT che sono preziosi da gestire. Persiste il bisogno di liberarsi dei costi e dell’onere della gestione della propria struttura e una risposta plausibile per sostenere la crescita del cloud sono le proposte di colocation.

I cloud ospitati “privatamente” maturano una maggiore quantità di entrate rispetto al cloud pubblico. Parliamo sia di risorse all’interno dei data center aziendali sia di colocation, rispetto all’offerta hyperscale.

Il data center si trasforma

Oggi la migrazione del DC tiene conto poi di altri fattori perché il data center si sta trasformando. Anche per le esigenze  aziendali sempre di nuove applicazioni che, sviluppate sfruttando DevOps e native per il cloud, richiedono un cambiamento sostanziale nella gestione dell’infrastruttura. Questa trasformazione inverte il trend della concentrazione in grandi strutture.

L’esigenza di elaborazione sui big data genera data lake che saranno per lo più fatti risiedere in mega data center cloud gestiti da fornitori IaaS e SaaS o, meglio, in strutture più piccole posizionate che siano posizionate in modo favorevole, a livello geografico, in termini di latenza e risposta di servizio. 

Nel corso del prossimo anno le aziende preferiranno concentrare gli sforzi su DC di piccole dimensioni rispetto ai grandi DC ma posizionati in modo strategico 

Il trend in atto prevede che un’azienda su quattro potrebbe abbandonare il consolidamento di grandi data center a favore della modernizzazione di data center di più piccole dimensioni posizionati più strategicamente. 

Dati di mercato dicono che i ricavi del cloud privato/ibrido siano stati circa il 43% maggiori delle entrate del cloud pubblico e siano cresciuti solo del 2% meno rapidamente. Inoltre, mentre le società iperscaler continuano a costruire siti, non hanno abbastanza capacità per supportare da soli questa crescita prevista e si rivolgono sempre più spesso a fornitori di colocation per ottenere aiuto.

Migrazione DC, passo a passo

Gartner, Idc e 451 Research concordano sui numeri. Ad oggi oltre il 50% delle migrazioni DC supera i limiti di budget e il 60% di esse viene ritardato rispetto alle tabelle di marcia. Non solo, in un caso su due si registrano downtime in seguito alla migrazione, ma soprattutto stupisce il fatto che in due casi su dieci la migrazione sia stata compiuta senza avere un effettivo piano!

La creatività nella gestione di un piano di migrazione è contemplata solo per riuscire ad adeguare al meglio il metodo al caso specifico.

Perché si migra? Pianificare è tutto

E il metodo prevede la capacità di individuare perché si migra (1), individuando a monte i criteri di valutazione su cui si misurerà il successo o meno dell’operazione e la strategia da 1 a 3/5 anni; la pianificazione dell’operazione (2), che comprenda un’analisi delle risorse in campo e da mettere in campo, ma anche dell’infrastruttura in relazione alle applicazioni che la sfruttano.

Conta la squadra, ma serve un leader

Si tratta di un’operazione di squadra che però deve prevedere un unico capo progetto, che si possa relazionare con l’eventuale partner e deve essere affiancato da un assistente “di backup”. Leadership chiara, ma anche continuità operativa garantite. La terza fase, quella dello sviluppo effettivo (3), in questa fase si gettano le basi dell’operazione.

Non sempre si tratta di “costruire l’infrastruttura”, si può trattare invece di individuare quale proposta tecnologica, tra quelle scelte sia in grado di supportare al meglio l’iniziativa. In questa fase la migrazione di progetti diversi può vedere l’attivazione di risorse umane diverse, a patto di chiarire in anticipo le linee di comunicazione.

E bisogna predisporre quindi le nuove risorse. La parte difficile consiste nel poter argomentare che l’applicazione non si deteriorerà e non subirà crash irrimediabili durante la migrazione. Significherebbe il mancato prestazioni degradate e tempi di inattività oltre i limiti di Sla accettabili.

La creazione di un piano di emergenza per la migrazione dell’applicazione è essenziale per conquistare la fiducia (4) – non solo dei “piani alti” – in modo che la migrazione possa avvenire. Più si riesce a coinvolgere le risorse che hanno sviluppato i servizi o li usano e allinearle alle eventuali problematiche (confortandole sulle possibilità di ripristino), più saranno cooperative. La loro partecipazione è fondamentale sia dal punto di vista tecnico che funzionale. 

Dati e sicurezza

La migrazione in uno scenario di colocation, come presso un provider o nel cloud pubblico riguarda lo “spostamento” dell’hardware. Ma ovviamente implica migrare i dati stessi su nuove apparecchiature. La nuova casa dei dati pone la necessità di porsi nuovi interrogativi (5).

Non ci si aspetta di sicuro che i dati vengano persi o che si verifichi una duplicazione indesiderata. Spesso gli ambienti vecchi e nuovi utilizzano formati e profili di dati diversi. I passaggi critici per i dati saranno: estrazione (è il momento di pensare al backup), trasformazione (ove necessaria sia verificata), pulizia (bisogna rimuovere istanze di duplicazione e risolvere eventuali problemi di corruzione), convalida, migrazione.

Dati e sicurezza – Due aspetti critici nella migrazione del DC

Poiché i set di dati stanno diventando esponenzialmente più grandi, sono più cogenti anche i requisiti di privacy (6), sicurezza e conformità. Soprattutto in settori verticali come l’assistenza sanitaria e l’e-commerce.

Quindi, se la strategia di migrazione include un cloud sicuro o una combinazione di colocation e servizi gestiti, bisogna assicurarsi che gli standard e i requisiti di conformità alle normative siano soddisfatti. Il passaggio contribuirà notevolmente a garantire l’integrità dei dati e contribuirà alla tutela della reputazione dell’azienda.

Se è tutto in ordine…Si migra!

Con il settimo step si chiude in pratica la fase “prospettica” e ci si apre alla fase operativa. E’ l’ultima fase di verifica di ogni passaggio prima della migrazione effettiva e non a caso viene qualificata dagli addetti ai lavori come la fase di validazione. E’ una fase di “check and balance”: risorse di storage, networking, computing e sicurezza sono allineati? E’ possibile fare off/on? Si pensa almeno di essere in grado di rispondere nel caso qualcosa vada storto? Di spegnere sono capaci tutti, riaccendere è un altro affare.

Ci siamo (8) si migra: i piani sono stati definiti, le risorse predisposte e verificate, le dipendenze applicative sono state analizzate. E’ sufficiente? No certo. Solo i folli – quando potrebbero farlo- procedono senza un test. I test hanno salvato tante teste, ma non sono sempre possibili. A meno che non si scelga la saggia via di tentare una migrazione del backup. Si mettono in gioco quindi processi, app e dati non in produzione, ma di backup. Dopo questa verifica, si aggiusta il tiro e si procede.

Gestire bene per crescere

E poi? Secondo manuale e logica mancano gli ultimi due passaggi. Sarà un piacere arrivarci e potrete farlo se avete operato bene voi e bene i vostri partner. Il primo riguarda la gestione (9) della nuova infrastruttura.

Che sia partita bene non vuol dire che proceda bene, monitorarla è il minimo, è però anche necessario verificare che oltre la “produzione” anche tutte le altre attività a valle siano allineate.

Lo si capirà nel tempo, per questo è opportuno allocare risorse dedicate – maggiori ed eccezionali rispetto ai periodi ordinari – a fare in modo che l’impatto sia minimo nel caso in cui qualcosa andasse storto.

Se tutto è andato bene il business crescerà e sarà presto tempo di scalare (10), ma questa è un’altra storia. Resta il consiglio di sempre: “meglio capire bene dove si sta andando, per non finire a caso dove non si sarebbe mai pensato”.

“What’s next?” quando si parla di futuro.
Non perdere tutti gli approfondimenti della Rubrica WhatsNext

© RIPRODUZIONE RISERVATA