Prima di affrontare una migrazione al cloud, occorre definire alcune scelte chiave — le più importanti ruotano attorno al valore di business atteso. Scopra cos'altro deve sapere.
Valuti l'idoneità di ogni workload prima di portarlo nel cloud o su una piattaforma cloud diversa
Il passaggio al cloud pubblico non è un traguardo, ma il primo passo di un percorso continuo. Se ha già padroneggiato le fasi chiave di una migrazione al cloud per alcuni dei suoi workloads, è probabile che in futuro decida di spostarne altri. Oppure potrebbe trovarsi a migrare verso un cloud diverso per ridurre i costi, ottenere funzionalità migliori o maggiore sicurezza. Ma prima di muovere qualsiasi cosa, occorre porsi alcune domande fondamentali.
1. Ha il sostegno della direzione?
Se la risposta non è un "sì" convinto, la migrazione al cloud è destinata a fallire. Sebbene la maggior parte delle aziende punti a portare nel cloud l'80% del proprio hosting IT entro il 2024, sono pochi i dirigenti C-level pienamente convinti che le iniziative di migrazione della propria azienda produrranno i risultati promessi. Ecco perché è essenziale considerare il cloud come qualcosa di ben più ampio di un semplice progetto IT. Serve l'adesione della leadership al cloud come piattaforma per alimentare l'efficienza, l'innovazione e la crescita che garantiranno il successo futuro dell'azienda.
Quel tipo di adesione si conquista con un piano di migrazione persuasivo, che dimostri un approccio attento, sistematico e strategico a cosa migrare e dove e – soprattutto – a quale problema di business intende risolvere. Tenga conto della crescita attuale, delle dimensioni e dei punti critici della sua azienda per costruire un caso convincente sul reale valore di business che la migrazione potrà generare.
2. Cosa vuole ottenere l'azienda con questa migrazione?
Gartner prevede che la quota di nuovi workloads digitali distribuiti su piattaforme cloud-native salirà dal 30% del 2021 a oltre il 95% nel 2025. Prima di trasferire workloads su cloud diversi o di portare nel cloud quelli ancora on-premises, le aziende devono avere chiare le ragioni che le spingono in quella direzione.
Tra i fattori trainanti rientrano il risparmio sui costi, l'alleggerimento del peso infrastrutturale, la scalabilità, la disponibilità e una migliore esperienza utente. Forse la crescita sta mettendo a dura prova i sistemi e l'infrastruttura on-premises e servono nuovi sistemi capaci di scalare al passo con il business. Oppure l'obiettivo è snellire le procedure per sviluppatori e utenti, rendere l'IT più efficiente per rispondere prima alle esigenze dei clienti o aumentare l'agilità per reagire più velocemente ai cambiamenti del mercato globale.
La migrazione al cloud permette di liberare l'innovazione su larga scala e a ritmi sostenuti, consentendo alle aziende di raggiungere traguardi decisivi che, senza il cloud, richiederebbero anni. Qualunque sia l'obiettivo, i leader aziendali devono avere chiaro lo scopo della migrazione, in modo da poter monitorare e misurare i progressi verso il suo raggiungimento.
3. Questo workload è un buon candidato per il cloud?
Portare nel cloud pubblico molte applicazioni frontend ha senso, perché la loro tendenza a cambiare di frequente trae beneficio dalla flessibilità che il cloud offre. I workloads più adatti al cloud tendono ad avere cicli di vita brevi, picchi di utilizzo ricorrenti e necessità di un rapido provisioning dell'infrastruttura.
Ma non ogni workload è una buona scelta per il cloud. Le applicazioni che richiedono latenze inferiori al millisecondo, in genere, è meglio mantenerle on-premises. Se gestisce un sistema di trading finanziario, ad esempio, il cloud non sarebbe la soluzione ideale per quella parte della piattaforma. Anche il manifatturiero è un settore particolarmente sensibile ai ritardi temporali: ecco perché alcuni dei più noti costruttori automobilistici utilizzano sistemi come AWS Outposts per sviluppare ed eseguire applicazioni nei propri stabilimenti, evitando la latenza relativamente alta che il cloud comporterebbe rispetto all'on-premises.
Un altro caso in cui mantenere i workloads on-premises può essere la scelta migliore – almeno nel breve o medio termine – è quando ha investito ingenti Capex (spese in conto capitale) nella propria infrastruttura on-premises e deve ottenerne il massimo ritorno prima di passare al modello finanziario Opex (spese operative) tipico del cloud.
Tuttavia, contrariamente a quanto si pensa spesso, la compliance non rientra in genere tra i motivi per tenere un workload on-premises. Anzi, le maggiori possibilità di visibilità e i controlli più granulari rendono il cloud, a ben vedere, una collocazione anche più adatta per workloads di questo tipo. Si pensi al GDPR dell'UE: con la dovuta attenzione alle normative e una solida conoscenza del cloud, è possibile ottenere un ritorno sull'investimento superiore con un deployment cloud rispetto a un data center.
È utile rivolgersi a un partner cloud per un'analisi approfondita dei workloads, così da individuare il modello di deployment ottimale. Otterrà un quadro chiaro del panorama tecnico, delle sfide e delle dipendenze degli attuali workloads, del valore della migrazione rispetto allo sforzo richiesto e della sequenza migliore con cui procedere.
4. Perché proprio questo cloud?
Sebbene la maggior parte delle organizzazioni utilizzi più cloud, non sempre lo fa in modo efficiente o strategico. In parte perché molte iniziative di cloud pubblico nascono come shadow IT, con software, dispositivi e servizi acquistati all'insaputa o al di fuori del controllo del reparto IT.
I workloads vengono inoltre assegnati ai cloud per opportunità del momento, più che sulla base di un'analisi. Senza dati accurati sulle prestazioni dell'infrastruttura per ciascun workload, scegliere il cloud giusto diventa una questione di fortuna, non una decisione informata.
Si interroghi sui motivi per cui sta spostando i suoi workloads su un determinato cloud. I principali provider hanno tutti punti di forza specifici che possono adattarsi al suo caso d'uso. Ad esempio, molti clienti migrano ad Amazon Web Services (AWS) per l'ampiezza e la profondità dei suoi servizi, i clienti Microsoft scelgono spesso Azure per innovare con servizi che già utilizzano e Google Cloud si distingue per le sue capacità di data analytics.
In teoria, è possibile far girare lo stesso workload su più cloud, ma in questo modo ci si limita al minimo comune denominatore. Ogni provider offre servizi nativi non disponibili presso i concorrenti, quindi non è realistico aspettarsi che i workloads funzionino in modo trasparente su qualsiasi piattaforma. Sfruttare il cloud pubblico per l'innovazione che abilita significa puntare sui punti di forza del cloud prescelto al momento di decidere dove distribuire i workloads.
5. Quale approccio adotterà per la migrazione?
A seconda della sua precedente esperienza con la migrazione al cloud e dell'accesso della sua azienda alle competenze adeguate, l'approccio rientrerà in una (o in una combinazione) di cinque categorie: rehost (lift and shift), refactor, replatform, rebuild, replace o retire:
- Il rehosting è l'approccio più diretto: consiste nel ridistribuire dati e applicazioni esistenti su risorse di storage e compute cloud senza alcuna modifica. Richiede competenze cloud relativamente limitate, ma non sfrutta le potenzialità del cloud e non si adatta a tutti i workloads.
- Il refactoring è più complesso perché prevede una nuova progettazione architetturale delle applicazioni prima di portarle in ambiente cloud, ma offre anche un ritorno sull'investimento elevato perché valorizza appieno le funzionalità cloud-based e la loro intrinseca flessibilità ed elasticità.
- Il replatforming è una via di mezzo tra rehosting e refactoring: prevede alcune modifiche al workload per sfruttare i vantaggi abilitati dal cloud, come l'automazione e una migliore scalabilità.
- Il rebuilding ricrea sostanzialmente il workload da zero per sfruttare appieno le funzionalità dell'ambiente cloud. Richiede competenze e impegno elevati.
- Sostituire i workloads con un'applicazione cloud-native significa dismettere l'applicazione esistente e migrare solo i dati necessari per farla funzionare. Può essere una scelta prudente quando è più semplice usare un servizio offerto dal vendor cloud che provare a riportare gli stessi strumenti utilizzati on-premises.
- Dismettere i workloads che hanno esaurito la loro utilità è importante per non sprecare tempo e risorse durante la migrazione. Tuttavia, prima di dismettere qualsiasi cosa è fondamentale identificare le eventuali dipendenze a monte.
L'approccio di migrazione che sceglierà influenzerà tutto, dai costi cloud alle decisioni architetturali.
6. Quanto costerà?
Il budget di una migrazione al cloud deve tenere conto di tutte le fasi del processo, dalla pianificazione preliminare fino all'esercizio dei workloads nel cloud dopo il go-live. Anche se la leadership è concorde sulla necessità di migrare, deve avere piena consapevolezza dei costi in gioco per decidere come procedere e a quale ritmo.
Il Cloud Total Cost of Ownership (TCO) è il metodo utilizzato per calcolare i diversi costi legati al funzionamento dei workloads nel cloud lungo l'intero ciclo di vita. Ogni deployment cloud è diverso, ma è essenziale confrontare quanto costa eseguire la stessa applicazione on-premises e nel cloud. La funzionalità dell'applicazione va considerata nel suo complesso, in particolare requisiti come la sicurezza, le dipendenze da altre applicazioni e tutti gli ambiti che possono incidere in modo significativo sui costi. Un altro elemento importante del TCO cloud è il costo per colmare le lacune di competenze e portare i team al passo con le diverse piattaforme cloud coinvolte nella migrazione.
7. Quali sono le implicazioni della migrazione su sicurezza e compliance?
I controlli e le pratiche di sicurezza pensati per gli ambienti on-premises non funzioneranno nel cloud. Una delle principali differenze a cui dovrà adeguarsi è il modello di responsabilità condivisa: il provider cloud si fa carico della maggior parte della responsabilità sulla sicurezza dell'infrastruttura, mentre il cliente è responsabile delle configurazioni e delle impostazioni sotto il proprio controllo diretto, come dati e applicazioni. Lo si può anche definire come la differenza tra "of the cloud" e "in the cloud": il vendor risponde della sicurezza del cloud, il cliente della sicurezza di ciò che è dentro al cloud.
Un'altra particolarità della sicurezza cloud è che la sua natura software-based introduce requisiti specifici per controlli e processi che potrebbero richiedere nuove tecnologie. Potrebbe inoltre dover ridisegnare i flussi di governance e i loro allineamenti per renderli più agili e continuativi. Si prepari a coinvolgere rappresentanti di un'ampia gamma di stakeholder e discipline tecniche.
8. Ha accesso alle risorse necessarie per portare a termine la migrazione?
La carenza di personale IT qualificato sta rallentando l'adozione delle tecnologie legate al cloud. Nella sua Emerging Technology Roadmap 2021-2023, Gartner ha rivelato che i dirigenti IT considerano la carenza di talenti il principale ostacolo all'adozione delle tecnologie emergenti — database, machine learning, storage avanzato e analytics inclusi — tutte abilitate dal cloud.
Una volta acquisite le competenze necessarie, deve assicurarsi che il team operi come un'unica unità coesa: il processo si sgretola se, ad esempio, i suoi data engineers lavorano isolati dagli esperti di networking e ognuno considera concluso il lavoro non appena ha completato la propria parte. Incoraggi la partecipazione attiva di tutti e diffonda la cultura per cui nessuno ha finito finché non hanno finito tutti. È una delle ragioni principali per cui sono fondamentali il coinvolgimento e l'adesione degli stakeholder senior: solo così si evitano blocchi nella creazione di team trasversali a cui affidare il percorso cloud. Altrimenti, il progetto di migrazione si arenerà man mano che gli ostacoli si accumulano.
Se non dispone delle competenze interne per realizzare la migrazione, può valutare di formare e riqualificare il suo team affinché se ne faccia carico. Tenga però presente che si tratta di un processo che richiede tempo e che sottrae persone al lavoro di valore che già stanno portando avanti. Affidarsi a un partner cloud che abbia le competenze e l'esperienza per accompagnarla nella migrazione può rivelarsi una scelta prudente e accelerare il percorso grazie a indicazioni solide, fondate sull'esperienza di architetti consolidati.
9. Qual è il prossimo passo?
Dopo essersi posto tutte queste domande, potrebbe chiedersi se disponga davvero delle competenze e delle risorse per portare a termine con successo una migrazione al cloud. C'è però un'alternativa: rivolgendosi a un partner cloud come DoiT, può contare su esperti di migrazione che la accompagnano lungo l'intero processo senza costi aggiuntivi.
In qualità di premier partner di AWS e di Google Cloud, offriamo competenze multicloud sostenute da preziose tecnologie di ottimizzazione, analytics e governance. Riceva supporto nella raccolta dei requisiti e nella definizione degli obiettivi di business, nella costruzione dell'architettura cloud più adatta e nello scaling dell'infrastruttura. Con un supporto come questo, la sua prossima domanda sarà soltanto: "da dove comincio?"