Per un'azienda passare al cloud non è mai tanto semplice quanto molti pensano. Quantomeno, non lo è per le aziende che hanno una cospicua "storia IT" alle loro spalle, cioé che hanno una buona quantità di sistemi, servizi e applicazioni, stratificati nel tempo, da passare nella "nuvola".

Ciascuna di queste componenti IT può essere in teoria portata in cloud, ovviamente, ma la questione cloud non si limita a questo. Nella nuvola non devono trasferirsi solo le singole componenti ma anche le loro relazioni ed interdipendenze, e che questo accada automaticamente e senza problemi non è affatto scontato.

Le aziende che hanno sperimentato il cloud - cioè, in sostanza, quasi tutte - hanno infatti imparato che è meglio fare valutazioni attente su come (e anche se) spostare determinate applicazioni in cloud. Ogni applicazione potrebbe richiedere un percorso differente verso il (multi)cloud pubblico o ibrido, percorso che ha costi e opportunità altrettanto differenti.

Analisti, vendor ed esperti hanno sempre cercato di definire modelli generici di migrazione che le aziende potessero seguire nella loro strategia cloud. Modelli ovviamente solo esemplificativi, dato che poi ogni impresa fa sempre storia a sé. Anni fa, Gartner presentò quello che ha avuto probabilmente il maggior successo di popolarità. Anche perché è stato "sloganizzabile" nelle ormai mitiche "cinque R" della migrazione in cloud delle applicazioni.

Le 5 R di Gartner

Lo storico modello delle 5 R di Gartner nasce nel 2011 e riflette lo scenario cloud di quegli anni, in cui il passaggio alla nuvola era considerato come il destino inevitabile, prima o poi, per qualsiasi applicazione che valesse la pena mantenere in vita. Così tutte le R previste portavano a una qualche forma di cloudificazione. Curiosità: Richard Watson, uno degli estensori delle 5 R, in realtà nel 2010 presentò un primo modello in cui le R erano solo 4: Refactor e Revise erano fuse in un singolo passo, Recode.

L'originale modello delle 5R di Gartner

Rehost

È il buon vecchio lift-and-shift che oggi piace a pochi. Non si fa altro che prendere l'applicazione, impacchettarla in qualche modo che possa essere traslato in cloud - di solito "dentro" una macchina virtuale - e la si implementa in un ambiente IaaS di un cloud provider. L'applicazione resta quella che era prima, cambia solo quello che c'è sotto.

Il rehosting è andato molto di moda ai primi tempi del cloud perché rappresentava la strada più semplice per fare evolvere le applicazioni. Lo è ancora, spesso: è una migrazione concettualmente immediata, la si può automatizzare, supporta anche migrazioni massive, comunque qualche vantaggio in termini di costi lo porta. È anche però la migrazione meno interessante, perché non sfrutta quasi nessun vantaggio del cloud. E portare in cloud un oggetto "vecchio" potrebbe comportare incompatibilità tecniche od operative tra ambienti diversi.

Refactor

Qui le cose un po' si complicano, perché il refactoring di Gartner del 2011 viene oggi spesso definito replatforming. Confusione a parte, anche il refactoring/replatforming ha un suo soprannome descrittivo che si usa spesso: lift-and-reshape, o anche lift-tinker-and-shift. Anche in questo caso l'architettura di base dell'applicazione non cambia, in nome della semplicità, ma qualcosa nel suo funzionamento sì, adottando opportune componenti PaaS. Un esempio classico: passare dalla gestione diretta dei dati a un servizio PaaS di database-aaS.

Il refactoring/replatforming viene considerato come un passo per ottimizzare - e meglio magari ridurre - l'utilizzo che una "vecchia" applicazione fa delle risorse IT e per darle una certa elasticità. Non è però una strada sempre veloce ed economica: l'applicazione e le sue interdipendenze vanno comunque analizzate bene per capire dove intervenire e dove no.

Revise

Delle 5 R di Gartner è quella che è andata più perdendosi nel tempo. Nell'idea iniziale il revising è una via di mezzo tra il refactoring stile Gartner e una rivisitazione totale dell'applicazione (nel linguaggio Gartner, il rebuilding che spieghiamo più avanti). Nel revising il codice iniziale viene modificato ed esteso per supportare i requisiti di modernizzazione del legacy, poi la (semi)nuova applicazione viene sottoposta a rehosting o refactoring per passare nel cloud.

L'aspetto negativo del revising è che implica un progetto di sviluppo comunque importante, che richiede impegno e risorse. Forse sin troppe per una modernizzazione tutto sommato intermedia.

Rebuild

È la strada "totale" del cloud, quella che oggi spesso viene chiamata refactoring. Significa ripensare, riprogettare e riscrivere da zero un'applicazione perché usi funzioni e componenti cloud-native. Idealmente questo processo trasforma una classica applicazione monolitica in un insieme sinergico di workload e microservizi, il che comporta elasticità, nuove funzioni, scalabilità, automazione, resilienza e tutti gli altri benefici chiave del cloud.

Anche qui, tutto vero. Ma è una strada ovviamente complessa che richiede il suo tempo, tempo che si paga in denaro e mancata (o minore) operatività. Se una determinata applicazione deve essere "future proof", il rebuilding/refactoring è la strada obbligata. Ma l'idea di cancellare facilmente il "technical debt" aziendale con una migrazione al cloud-native è tutta da verificare e di certo non si può procedere alla riscrittura di tutto il parco applicativo insieme: il rischio è bloccarsi del tutto.

Il rebuilding/refactoring insomma ha molto appeal, ma richiede una pianificazione accurata della migrazione, un monitoraggio costante della messa in atto del piano, un budgeting attento, la certezza di avere le skill cloud adeguate e un attento lavoro di ottimizzazione (anche dei costi) post-migrazione.

Replace

Il soprannome di drop-and-shop spiega tutto, in questo caso: l'applicazione originaria viene semplicemente abbandonata e si acquista una applicazione cloud in SaaS che fa le stesse cose. I vantaggi? Parecchi. Si sfruttano tutte le caratteristiche del cloud, si passa (presumibilmente) ad una applicazione più moderna ed estendibile con altre componenti cloud, si passa la gestione ai team del provider SaaS, si paga a consumo.

Solo che non sempre si può fare drop-and-shop "puro". Non è detto che esista una applicazione che fa esattamente le stesse cose della nostra, il che complica l'evoluzione delle applicazioni che hanno di partenza molte personalizzazioni (che in cloud si pagano anche care). Non a tutte le imprese va poi di perdere il controllo sulla gestione e sullo sviluppo di una applicazione magari critica.

Cosa è cambiato, dopo

Dal lontano 2011 molto è cambiato nel mondo cloud e anche la strategia generica di migrazione delineata da Gartner è stata rivista. Altri grandi nomi dell'IT e del cloud hanno presentato modelli diversi, sempre in qualche modo sovrapposti alle 5 R. Ma soprattutto si è aperta la strada a opzioni che in effetti non portano al cloud.

AWS in particolare, che nel cloud ha il suo peso, ha man mano introdotto un modello a 7 R che condensa i cinque passi di Gartner in quattro (Rehost, Replatform, Repurchase, Refactor) e ne aggiunge altri tre: Relocate, Retire e Retain.

Uno dei possibili modelli di migrazione delineati da AWS

Relocate

Relocate ha il soprannome di hypervisor-level-lift-and-shift ed è essenzialmente la trasposizione in un ambiente cloud del proprio ambiente di virtualizzazione on-premise. È quindi una "cloudificazione" per aziende già evolute, in grado tra l'altro di trasporre in cloud le licenze che già hanno per una piattaforma specifica di virtualizzazione. Che deve ovviamente esistere sia on-premise sia come servizio cloud.

Con gli strumenti giusti la relocation non è complessa, è relativamente rapida, comporta risparmi e non richiede di avere competenze in più o di cambiare i propri processi. Però è una strada limitata (la piattaforma di virtualizzazione quella è e quella rimane, in teoria) e bisogna valutare bene costi e scalabilità del nuovo ambiente cloud che si va a creare.

Retire

Per gli integralisti del cloud della prima ora le vecchie applicazioni monolitiche e legacy erano dirette verso un loro cimitero degli elefanti: quello che non poteva essere portato in cloud andava mandato in pensione, prima o poi.

Il retiring è un po' questo, ma basato su considerazioni più pragmatiche. In un processo di assessment in prospettiva cloud, spesso una azienda conclude che una certa quota delle applicazioni che possiede non serve davvero. Queste vanno eliminate, in modo che ciò che man mano si porta in cloud sia davvero quello che serve. Anche per evitare costi inutili.

Retain

Ci sono applicazioni che non possono essere portate in cloud o per le quali una migrazione non è abbastanza motivata o conveniente. Ma sono applicazioni che in qualche modo servono, quindi invece di pensionarle le si mantiene (retain) on-premise. Il Retain viene anche chiamato Revisit, perché questa valutazione va rivista periodicamente nel tempo. Sino a decidere, un giorno, che la specifica applicazione ancora on-premise può essere mandata in pensione.

Infine, alcuni ritengono che nelle strategie cloud ci sia spazio anche per una ottava R: Reimagine. È una R più motivazionale che altro, anche perché non indica esattamente una forma di migrazione ma piuttosto di innovazione. È un invito a re-immaginare applicazioni e processi di business tenendo presenti tutte le potenzialità offerte dai servizi cloud e dallo sviluppo cloud-nativo. Operativamente è un po' il refactoring/rebuilding, ma senza parire dall'idea di replicare semplicemente in cloud le funzioni offerte da una applicazione già esistente.