In uno scenario cloud sempre più ibrido, in cui il multicloud rappresenta una possibilità concreta di scegliere su misura servizi e risorse, le aziende hanno bisogno di riconoscere i workload applicativi che ancora oggi è necessario mantenere on-premise o migrare, e vogliono comprendere quando un’applicazione è da riscrivere del tutto per il cloud, oppure fino a quando sarà ancora utilizzabile così come è, magari perché vincolata alle linee di produzione.
Se è vero che la sfiducia verso il cloud computing oggi va scemando, resta quindi importante capire cosa migrare e come farlo. Vero questo, al punto che spesso, più che dal processo di migrazione in sé le aziende sono “spaventate” dall’idea di non inquadrare correttamente il proprio ecosistema di applicazioni e non riuscire quindi a “vedere” nel complesso il progetto.
Oltre il semplice lift&shift
E’ questo anche il limite più evidente di un approccio lift&shift. La migrazione in cloud non può essere considerata solo un processo tecnologico, ma implica spesso un ripensamento dei processi come delle metodologie utilizzate dall’applicativo.
Intendiamoci, questo tipo di migrazione non è di per sé sbagliata o inefficace, si tratta però di una migrazione “di base” che copre tutti gli scenari in cui un workload può essere spostato in cloud funzionando come prima senza necessità di intervenire su processi ecc.
Facciamo un semplice esempio: quando si ha a disponibile un backup locale e lo si sposta in uno spazio cloud è facile riconoscere che probabilmente non sarà necessario fare sviluppo ad hoc per far funzionare il servizio – tanto più se si migra un semplice repository – e anche una migrazione lift&shift si dimostrerà adeguata, tanto più che alcuni accorgimenti basilari sono previsti. E tuttavia non tutto è assimilabile a questo modello. E non sempre le condizioni sono ideali. Per questo il metodo resta un punto chiave.
Lo è quando si dispone di un unico data center, e pensando di essere prudenti si sceglie di migrare nel weekend, per concedersi un lasso di tempo significativo per eventuali recuperi. Così, anche nel caso in cui si hanno a disposizione due data center e uno solo è quello da migrare. Nel breve termine, se qualcosa va storto, ce la si potrà cavare, ma le criticità arriveranno alla ripresa dell’attività, quando non si disporrà più della “ruota di scorta”.
Primo step, quindi, può essere quello di operare in modalità across the wire. Con la disponibilità di due data center, si migra su un terzo. Il data center primario, e quello secondario, restano “accesi” fino a quando il terzo non sarà attivo.
Con i sistemi iperconvergenti oggi disponibili questa tipologia di migrazione è esperibile con successo. Ma abbiamo ancora guardato solo ad un lato della medaglia. Infatti, abbiamo parlato soprattutto di una migrazione di “risorse”: cosa accade invece quando parliamo di migrazione delle applicazioni che rappresentano – davvero – il cuore del sistema?
Le applicazioni, cuore del business
Il discorso quando si migrano processi e app è molto più complesso. Spieghiamo: potrebbe sembrare facile pensare allo spostamento di un’app con un semplice “re-hosting” della stessa, quindi prendendo l’intera applicazione dalla vecchia infrastruttura per spostarla in cloud, senza modifiche, senza aggiustamenti di codice, anzi, proprio estrando il codice da un ambiente e migrandolo ad un altro.
Cui prodest un approccio così semplicistico? La velocità è garantita, ma non si beneficerà per nulla delle funzionalità e degli strumenti che è in grado di offrire il cloud. L’app funzionerà probabilmente come avrebbe fatto su un server fisico, senza sfruttare la flessibilità e la scalabilità che gli ambienti cloud possono offrire.
Tra le possibilità però c’è anche quella che alcuni analisti definisco di “replatforming“. Il codice non viene alterato in modo significativo, ma si “insegna” all’app ad interagire con i database per trarre vantaggio da un’infrastruttura più efficiente. E’ possibile aggiungere nuove funzionalità per abilitare lo scaling e permettere all’app di beneficiare delle risorse dedicate in cloud.
Questo approccio può risultare conveniente, abilita la scalabilità in cloud senza riscrittura completa dell’app. Un punto critico c’è, bisogna misurare il processo di replatforming per non correre il rischio di spingersi troppo oltre gli obiettivi, cosa che potrebbe comportare modifiche di codice non necessarie. Facile intuire il terzo approccio, quindi.
Quasi non si parla nemmeno più di migrazione, perché con la reingegnerizzazione dell’app in pratica si riprogetta quasi del tutto l’applicazione per adattarla al cloud. Si parla di modifica consistente del codice che viene in parte riscritto proprio per sfruttare nel modo migliore le funzionalità cloud; una reingegnerizzazione che spesso porta caratteristiche equivalenti a quelle di un app nativa in cloud, senza stravolgimenti. E’ questo un approccio impegnativo, che porta frutto a patto di scegliere un partner valido che non abbandoni a metà del percorso.
Migrare, meglio insieme e ben accompagnati
L’approccio da cui parte Teorema è proprio questo. Si cerca di guardare all’ambiente del cliente come ad un ecosistema di applicazioni e di risorse, ben consapevoli dei limiti di un approccio semplicemente lift&shift.
Teorema piuttosto accompagna il cliente nella valutazione responsabile delle diverse opzioni di migrazione applicativa, con l’offerta anche di reingegnerizzazione delle applicazioni, in modo da ripensare, nel caso, anche ad una nuova modellizzazione per il cloud persino delle applicazioni business critical.
Teorema ha le competenze per farsi carico dello studio dell’ecosistema, verifica se le app possono essere “spostate” in un ambiente cloud e con quali conseguenze e vantaggi, aiuta a mantenere il controllo sulla gestione e sull’efficienza operativa delle stesse.
Quando, come spesso accade, il semplice re-hosting non è la soluzione adeguata, Teorema mette in gioco le sue competenze per lo studio della soluzione migliore e accompagna il cliente fino al completamento della migrazione.
E’ vero, i processi di migrazione sono questioni gravose, ma meno di quanto si tenda a immaginare, a patto di partire con il giusto approccio. Individuare il partner tecnologico in grado di “leggere” oltre la “tecnologia” e indirizzare, affiancando manager e collaboratori lungo il percorso di digital transformation è il primo passo da fare e va nella giusta direzione.
Teorema in particolare offre ai clienti una serie di attività specifiche legate al processo di change management. Si tratta di iniziative a totale supporto del cliente che permettano dal primo momento di imparare ad usare il nuovo ambiente in cloud.
Teorema, lavorando gomito a gomito con aziende attive in tutti i settori, soprattutto quelle che operano in ambiti critici come finance e manufacturing, ha sviluppato un know-how che va ben oltre il tema dell’efficacia delle soluzioni. Per questo si parla di strumenti veri e propri di change management.
Prima di avviare qualsiasi progetto di digital transformation, concorda non solo con l’innovation manager, ma anche con Cio, Cto e Ceo un piano di ascolto per vagliare quali sono le reali esigenze e comprenderle a fondo, così da costruire insieme agli utenti strumenti tanto usabili quanto efficaci, a tutti i livelli. Fondamentale per Teorema resta infatti il coinvolgimento di tutti gli attori.
Un esempio molto semplice delle attività messe in atto per supportare in modo continuo e costante i clienti è anche la stessa realizzazione dell’ON-Bot, come strumento per rispondere alle domande degli utenti. Sarà utilizzabile anche solo per rispondere alle domande, anche le più semplici, e capire come fare ad accedere alla casella di posta da web browser, come reimpostare la password, se è possibile e come accedere alla Intranet da casa e così via.
Le competenze necessarie a sostenere il piano di trasformazione possono essere sviluppate internamente ma anche essere integrate dall’esterno. Poter fare affidamento su persone e partner con competenze approfondite delle piattaforme tecnologiche permetterà l’affiancamento delle risorse umane interne che apprendono grazie a esperienze di prima mano come adoperare i nuovi strumenti e come massimizzare la produttività. Da qui anche la massima flessibilità nella gestione e nell’implementazione delle nuove componenti sul piano tecnico.
Potremmo definire questo un modello di prossimità flessibile che beneficia della capacità di dialogare con chi è chiamato ad agire sulle leve strategiche, per orientare lo sviluppo delle architetture e delle applicazioni in maniera coerente e integrata con le funzioni di business.
“What’s next?” quando si parla di futuro.
Non perdere tutti gli approfondimenti della Rubrica WhatsNext
© RIPRODUZIONE RISERVATA
