Introduzione
Nel panorama IT odierno le tecnologie Cloud hanno ormai preso piede in maniera preponderante con un numero sempre maggiore di aziende che adottano il nuovo modello per poterne sfruttare i numerosi benefici per la produzione di applicazioni innovative e altamente performanti.
Tra questi numerosi vantaggi possiamo citare:
- Maggiore affidabilità dell’infrastruttura globale sottostante.
- Scalabilità pressoché illimitata
- Agilità per una sperimentazione più aggressiva
- Modello a consumo (Pay as you go) senza necessità di investimenti iniziali
- Time To Market ridotto grazie alla possibilità di innovare più velocemente.
Negli ultimi anni, infatti, si sono moltiplicati i progetti di migrazione da infrastrutture classiche On-Premises ad infrastrutture Cloud e proprio per questo motivo sono state identificate, con l’andare avanti dei progetti, delle strategie di migrazione che permettono di identificare la migliore modalità con cui i vari workload possono essere spostati sui Cloud Service Providers (CSPs).
Queste strategie vengono chiamate in gergo 7 Rs.
Ad oggi sono state identificate le seguenti strategie di migrazione; tuttavia, è possibile che in seguito la lista venga ampliata con l’evolversi delle tecnologie ed il rilascio di nuovi servizi.
- Rehost
- Replatform
- Refactor (o Rearchitect)
- Repurchase
- Relocate
- Retain
- Retire
Rehost (Lift&Shift)
La strategia di Rehost consiste semplicemente nello spostare o muovere le varie macchine virtuali che sono presenti On-premises nei vari ambienti Cloud.
Questa strategia prevede una serie di benefici non indifferenti in quanto permette di incominciare ad entrare in contatto con le nuove tecnologie Cloud mantenendo un livello di modifiche agli applicativi d’origine minimo, se non nullo. Difatti, questa strategia, permette di atterrare sul Cloud e incominciare a sperimentarne i benefici con il minor impiego di risorse possibile.
Molte aziende, soprattutto quelle meno esperte, possono utilizzare un approccio di trasformazione two-step permettendo così di concentrarsi prima sulla componente di migrazione per focalizzarsi solo successivamente sulla fase di trasformazione delle applicazioni per incominciare a sfruttare i vari servizi Cloud gestiti.
Replatform
La strategia di Replatform consiste nel migrare un applicativo in Cloud ma apportando delle modifiche a determinate elementi/componenti dell’infrastruttura. L’esempio più classico che viene generalmente presentato è la migrazione della componente di DB a dei servizi gestiti per poter sfruttare i vari benefici che vengono offerti da questo tipo di servizi.
I benefici di questo tipo di strategia sono molti anche se, in fase di migrazione, viene più complesso applicarla in quanto oltre alla componente di lifting delle componenti che non verranno modificate bisognerà anche capire come muovere i vari componenti che sono oggetti del re-platforming ad altri servizi. Una volta terminata la migrazione, tuttavia, si possono già sfruttare i primi benefici dei nuovi servizi oltre che ad avere un’applicazione generalmente più affidabile e scalabile.
Rearchitect
La strategia di Rearchitect è generalmente considerata quella più complessa da applicare perché consiste in una totale riscrittura di tutta la logica di un’applicazione che nel corso del tempo può essere diventata obsoleta, non svolge più il proprio compito in maniera ottimale (ad esempio sono cambiati alcuni processi o procedure aziendali interne) oppure non è supportata sulla piattaforma Cloud scelta.
La strategia prevede di riscrivere ogni componente applicativo affinché sia pensato per funzionare sul Cloud e sfruttarne le caratteristiche e le potenzialità. Alcuni esempi possono essere la riscrittura di determinate web application in modo tale che sfruttino i servizi serverless forniti dai vari ecosistemi Cloud o la scomposizione di alcuni applicativi monolitici in architetture a microservizi.
I benefici di questa strategia sono innumerevoli perché permette la creazione di applicazioni Cloud-native che sfruttano le caratteristiche di affidabilità, performance e gestione dei vari CSP, tuttavia, operazioni di questo tipo vengono spesso difficilmente inserite in migrazioni perché oltre ad un livello di complessità nettamente maggiore rispetto alle altre due strategie presenta anche l’inconveniente del tempo in quanto effettuare il refactoring di un applicativo richiede generalmente molto tempo e molti test affinché quest’ultimo funzioni correttamente in Cloud.
Repurchase
Questa strategia prende anche il nome di Drop&Shop e viene generalmente utilizzata nelle migrazioni di software di terze parti protetti da licenza. Generalmente viene scelta questa strategia di migrazione quando bisogna andare a sostituire il software con un altro software, con una versione più aggiornata o in Cloud dello stesso o adottare software esposti in modalità SaaS con sottoscrizione.
Questa strategia presenta il benefit di poter migrare verso soluzioni in Cloud o più aggiornate di un prodotto terze parti permettendoci di evitare di spostare la macchina on-premise riducendo in questo modo anche la componente legata ai costi.
Relocate
La strategia di Relocate viene usata spesso in migrazioni On-premises to Cloud ma solo in quelle occasioni in cui si vuole effettuare un cambio o un refresh di infrastruttura fisica sottostante. Tutto ciò che infatti va dal livello del hypervisor in su (VM, OS, Librerie, ecc…) verrà mantenuto inalterato.
Un esempio molto pratico è una migrazione da on-premises vSphere a VMC. In questo caso andremo a cambiare solamente l’infrastruttura fisica sottostante senza intaccare minimamente i workload (manteniamo, in sostanza, lo stesso virtualizzatore).
Questa strategia presenta un grosso benefit che risiede nella facilità di migrazione in quanto permette di sfruttare i tool già forniti dai vari hypervisor per poter spostare le macchine virtuali nella nuova infrastruttura Cloud.
Retain
La strategia di Retain è una strategia di migrazione che consiste semplicemente nel non-migrare determinati workload in Cloud ma di tenerli on-premises. Questo approccio può sembrare controintuitivo in un primo momento ma viene spesso usato per tutti quegli applicativi che non possono, per un motivo o per un altro, essere migrati in Cloud (ad esempio non sono supportati dal CSP oppure il loro refactoring richiederebbe troppo tempo) ma che sono comunque applicativi di business ancora utilizzati nella realtà aziendale.
Retire
La strategia di Retire viene applicata nelle stesse misure in cui viene applicata quella di Retain ma la differenza sostanziale è che in questo caso gli applicativi in scope sono generalmente applicativi legacy, obsoleti o che non portano più alcun valore di business e che a seguito di un’analisi più approfondita si è scoperto non servire più nella realtà aziendale. In questo caso gli applicativi vengono semplicemente dismessi riducendo così il numero di macchine in perimetro per un’eventuale migrazione in Cloud.