Cloud Blog: Insights52 - Bottega52

Migrazione in Cloud di sistemi legacy - Bottega52

Scritto da Bottega52 Staff | Oct 7, 2021 4:00:00 AM

Probabilmente non esiste business in cui non sia presente almeno un software on premise che, pur avendo un utilizzo quotidiano o quasi, sia ormai da considerare come legacy. Molto spesso questi software rappresentano un freno alla crescita: sono lenti e poco affidabili, oppure richiedono attività di manutenzione e aggiornamento di server e hardware con costi rilevanti. Eppure, questi software sono parte integrante della value chain, e dunque dismetterli non è un’opzione, vanno gestiti e gestiti al meglio. Qui entra in gioco la Cloud Migration, che viene spesso identificata come l’occasione ottimale per un revamping del software legacy.

Il Cloud presenta infatti tre caratteristiche che, applicate a tali software, paiono promettere la soluzione dei problemi appena identificati: 

  • è scalabile in orizzontale e in verticale in modo molto flessibile e rapido
  • è resiliente e permette di reagire agli errori tornando in uno stato completamente funzionante il più rapidamente possibile
  • è basato su modelli di pricing  pay-as-you-go


Tuttavia, sono molte le variabili da considerare per completare con successo una Cloud Migration, e la quantità e le caratteristiche di queste rendono l’operazione ardua da affrontare per un reparto IT di matrice tradizionale. A cominciare dalla strategia da seguire per la migrazione. Perchè le vie possibili sono diverse e non esiste un criterio unico per definire quale sia quella da adottare. Ecco dunque che il responsabile dell’attività deve subito affrontare alcune valutazioni. Vediamo insieme possibilità e relativi trade-off   benefici/rischi.

Trasferimento di Host

La prima alternativa, la più semplice da concepire, è indubbiamente il trasferimento dell’applicativo così com’è su un ambiente Cloud. Un primo passo, che permette di liberarsi da problematiche e vincoli imposti dall’hardware e che potrebbe rappresentare un primo step di una strategia più articolata, in cui l’attività di Re-hosting è propedeutica a successivi interventi sull’applicativo, per sfruttare meglio i vantaggi del Cloud. 

 

Benefici

  • Possibilità di ricorrere a strumenti di automazione per supportare il processo di migrazione e renderlo più affidabile e solido
  • Adeguatezza delle competenze sviluppate in ambito sistemistico e di gestione di infrastrutture virtualizzate on-premise per procedere con l’attività
  • Tempistiche di migrazione più contenute rispetto ad altri metodi
  • Riduzione delle risorse utilizzate a livello di infrastruttura e delle attività per la loro gestione, con contemporanea dismissione delle  costose risorse on-premise 
  • Acquisizione di competenze sulla soluzione Cloud e sulle peculiarità del Cloud utili ad agevolare gli ulteriori step di evoluzione


Rischi

  • Mancata rivalutazione dell’infrastruttura, con conseguente sovradimensionamento delle risorse e dei costi
  • Incompleto sfruttamento delle potenzialità del Cloud, soprattutto per gli aspetti di scalabilità orizzontale e verticale
  • Aumento della latenza dell’applicativo a causa di una differente connettività

Utile per..

  • Applicativi di terze parti non destinati ad una Cloud Migration a medio o breve termine
  • Applicativi monolitici non idonei a supportare una progressiva trasformazione 
  • Soluzioni legacy basate su tecnologie obsolete
  • Applicativi pesantemente integrati con elementi esterni o di terzi
  • Soluzioni ad alto impatto sulle risorse infrastrutturali
  • Soluzioni in una fase matura del ciclo di vita e soggette a rari aggiornamenti

Trasferimento di piattaforma 

Uno step in più verso una soluzione maggiormente in grado di sfruttare le peculiarità del Cloud è il cosiddetto Re-platforming, in cui l’applicativo che viene trasferito in Cloud viene anche modificato sostituendo alcuni componenti con dei servizi gestiti erogati dal MSP, così da sfruttare al meglio le specificità della piattaforma di destinazione.

 

Benefici

  • Riduzione delle risorse utilizzate a livello di infrastruttura e delle attività per la loro gestione
  • Migliore sfruttamento delle caratteristiche proprie del Cloud 
  • Sviluppo di una conoscenza più profonda del Cloud e dei servizi che offre senza modifiche radicali al software


Rischi

  • Necessità di competenze specifiche sui sistemi Cloud e tecniche di refactoring 
  • Aumento del rischio di instabilità dell’applicativo in caso di trasformazioni multiple contemporanee e conseguente necessità di un’accurata attività di testing.


Utile per..

  • Applicativi con architetture multilivello o modulari
  • Soluzioni che fanno uso di servizi esterni sostituibili (ad esempio servizio SMTP o di autenticazione)
  • Attività mirate al miglioramento della scalabilità
  • Applicativi oggetto di frequenti modifiche
  • Soluzioni di cui si può modificare il codice sorgente per le parti di interfacciamento 

Rifattorizzazione/Creazione di una nuova architettura

La soluzione ideale per ottenere davvero tutti i vantaggi del Cloud sarebbe ridisegnare e sviluppare ex-novo l’intero sistema in ottica Cloud-native, attraverso un processo di redesign iterativo ed incrementale che miri ad adottare appieno i servizi Cloud-native offerti dai Cloud service provider per massimizzare i benefici che ne derivano.

Questa strategia, detta anche di Re-architecting, non va pensata come necessariamente da svolgere totalmente in modo autonomo, ma può venire effettuata ricorrendo anche all’integrazione di applicativi e tool Open Source già esistenti, per accelerare lo sviluppo e ridurre il costo totale di riscrittura.

 

Benefici

  • Massima riduzione delle risorse di infrastruttura e delle attività per la loro gestione
  • Ottimizzazione dei costi a lungo termine grazie ad un uso delle risorse mirato all’effettiva necessità
  • Migliore sfruttamento delle caratteristiche proprie del Cloud 
  • Abilitazione di logiche di matrice DevOps
  • Possibilità di scaling in real time
  • Incremento della sicurezza


Rischi

  • Difficoltà nel reperire le competenze Cloud necessarie per le trasformazioni che si vogliono operare
  • Aumento del rischio di instabilità dell’applicativo in caso di trasformazioni multiple contemporanee
  • Rischio di significativo lock-in con il Cloud service provider


Utile per..

  • Soluzioni con un ruolo  centrale nella strategia digitale del business
  • Applicativi caratterizzati da uno stack tecnologico obsoleto o in cui comunque una riduzione del debito tecnico è funzionale ad un elevato ritmo di evoluzione
  • Soluzioni ad alta variabilità di traffico


Hai visto qui?

Abbiamo molti altri articoli da leggere, vai a vedere!

Insights52
,---------------------------------------.---------.    
|                                       |         |    
|    ,-----------------------------.    |    .    |    
|    |                             |    |    |    |    
|    |    ,-------------------.    |    |    |    |    
|    |    |                   |    |    |    |    |    
|    |    `----     ,----     |    |    |    |    |    
|    |              | @       |    |    |    |    |    
|    |    ,---------"---------:    |    `----'    |    
|    |    |                   |    |              |    
|    `----:    ,---------.    |    `---------.    |    
|         |    |         |    |              |    |    
|    .    |    |    .    |    |     ---------'    |    
|    |    |    |    |    |    |                   |    
:----'    |    |    |    |    |    ,--------------:    
|         |    |    |    |    |    |              |    
|    .    |    `----'    |    |    |     ----.    |    
|    |    |              |    |    |         |    |    
|    `----"---------     |    |    `---------'    |    
|                        |    |                   |    
`------------------------'    `-------------------'

 

Smantellamento 

Non è poi così raro il caso in cui, analizzando l’applicativo in questione, ci si rende poi conto che in realtà esso non è necessario – almeno, non nella sua totalità. In questi casi,  analizzare i processi nella value chain e capire cosa crea valore per davvero è il primo passo da fare, per identificare con precisione il subset di funzionalità realmente utile al business e, di contro, gli applicativi che non sono più utili e possono essere spenti adottando la strategia di Retire

Si tratta di una strategia da gestire con estrema attenzione,  verificando eventuali utilizzi da parte di operatori o dipendenze verso altri sistemi non noti ma in realtà ancora attivi e definendo le modalità di espletamento dopo lo smantellamento delle eventuali necessità ancora presenti e non più coperte dalle funzionalità dell’applicativo da dismettere.

 

Benefici

  • Dismissione dell’infrastruttura a supporto dell’applicativo
  • Soluzione dei problemi di reperibilità delle competenze necessarie al supporto specializzato su applicativi legacy
  • Focalizzazione delle risorse sulle funzionalità realmente utili


Rischi

  • Errata mappatura di usi e dipendenze, con necessità di ripristino delle funzionalità dismesse
  • Necessità di un adattamento dei processi interni


Utile per..

  • Applicativi non più utili
  • Applicativi rimpiazzati da versioni più moderne ma mantenuti attivi unicamente per l’accesso a dati storici non migrati ai nuovi sistemi
  • Applicativi già destinati a dismissione ma ancora attivi per questioni di tempo, budget o competenze


Sostituzione 

Un altro evento piuttosto frequente è la scoperta dell’esistenza di software alternativi già disponibili sul mercato capaci di offrire le medesime funzionalità e le features attualmente gestite tramite il software legacy, ma gestite in modalità SaaS. Queste versioni alternative possono essere realizzate dal medesimo produttore del software legacy o rappresentare soluzioni equivalenti o migliorative proposte da nuovi soggetti. E’ il caso, ad esempio, di CMS, ERP, LMS, tool di Project Management o file sharing, ecc. La strategia di Re-purchase consiste proprio nel rimpiazzare il vecchio applicativo on-premise con la controparte SaaS, a cui l’utente può accedere semplicemente attraverso un browser o un’app, senza alcuna responsabilità infrastrutturale o manutentiva. Tipicamente, il loro pagamento è basato su di una sottoscrizione o un modello di pricing basato sull’effettivo consumo.

 

Benefici

  • Dismissione dell’infrastruttura a supporto dell’applicativo on premise
  • Contenimento dei costi iniziali e dei tempo di fermo per gli aggiornamenti dei sistemi 
  • Accessibilità indipendentemente dal luogo o dal device 
  • Flessibilità nel rispondere a variazioni delle esigenze di business
  • Disponibilità in modalità pronta all’uso, senza bisogno di setup iniziali


Rischi

  • Lock-in con il Cloud service provider 
  • Necessità di adeguare i dati da migrare ad un modello differente
  • Migrazione dei punti di integrazione (es. API) verso contratti differenti
  • Integrazione/riconfigurazione dei servizi SaaS con servizi on-premise 
  • Assenza di controllo in caso di down


Utile per..

  • Software con opzioni SaaS alternative disponibili sul mercato
  • Soluzioni che permettono una valida attività di migrazione dei dati


Conservazione 

In ultimo, un’attenta analisi potrebbe portare a scoprire che la scelta più saggia potrebbe essere quella di non migrare affatto ma attuare una strategia di Retain, ovvero non migrare in Cloud un determinato applicativo e mantenerlo on-premise per un ulteriore lasso di tempo, dopo il quale sottoporlo a nuovo esame.

 

Benefici

  • Contenimento dei tempi di  latenza della comunicazione 
  • Salvaguardia di investimenti collegati a eventuali forme di incentivazione in corso
  • Compliance a requisiti di sicurezza e privacy dei dati personali fortemente vincolanti


Rischi

  • Mancato ottenimento dei vantaggi economici ed operativi promessi dal Cloud


Utile per..

  • Soluzioni che richiedono una connettività minima pari alla rete locale
  • Soluzioni prive di alternative SaaS o incompatibili con le attuali piattaforme Cloud
  • Applicativi legati ad importanti investimenti in licenze on-premise non recuperabili o trasferibili


Scegliere la strategia ideale per migrare in Cloud un software legacy

Come si vede, le strategie possibili sono diverse e generalmente non esclusive. Un  tecnico che si trova a dover progettare la migrazione in Cloud di un software legacy deve necessariamente porsi una serie di  domande di alto livello piuttosto complesse e talora esulanti dal suo perimetro di esperienza ed operatività. Per scegliere la soluzione ideale, infatti, sono necessarie valutazioni tecniche, di business e strategiche, ma anche un’ottimale conoscenza delle possibilità presenti sul mercato Cloud. 

Bottega52 affianca le aziende nel percorso di migrazione in Cloud dei propri software legacy con un’attività completa, che permette al cliente di restare focalizzato sul proprio business. Base di questa attività è il Cloud Migration Workshop, una sessione di approfondimento guidata da personale esperto di Bottega52 e realizzata con il coinvolgimento di tutti i principali stakeholder dell’azienda, mirata a definire esigenze, peculiarità e attese del processo di migrazione.

Grazie alla propria expertise tecnica, al costante aggiornamento sulle opzioni disponibili sul mercato e all’approccio Cloud Native, Bottega52 può gestire con dimestichezza tutte le strategie di migrazione viste finora, effettuare una valutazione del rapporto costi /benefici offerti dalle diverse soluzioni per la specifica applicazione e definire un percorso di Cloud Migration con milestone e tempistiche precise da rispettare, a salvaguardia dell’investimento. In caso di Re-architecting, inoltre, Bottega52 offre un ulteriore valore aggiunto, ovvero la capacità di gestire l’intero processo di Enterprise Digital Product Design.

 

Ti piace leggere?

A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti

Library di Innovazione Digitale
       .--.                   .---.
   .---|__|           .-.     |~~~|
.--|===|--|_          |_|     |~~~|--.
|  |===|  |'\     .---!~|  .--|   |--|
|%%|   |  |.'\    |===| |--|%%|   |  |
|%%|   |  |\.'\   |   | |__|  |   |  |
|  |   |  | \  \  |===| |==|  |   |  |
|  |   |__|  \.'\ |   |_|__|  |~~~|__|
|  |===|--|   \.'\|===|~|--|%%|~~~|--|
^--^---'--^    `-'`---^-^--^--^---'--'