La migrazione verso il cloud è un metodo efficace per aumentare la produttività, l’innovazione e beneficiare di nuove tecnologie. Ma una volta studiata la strategia, va messa in atto una tattica che non necessariamente è uguale per tutte le aziende.
Le modalità di migrazione in cloud possono essere diverse e l’approccio dipende da diversi fattori che includono:
- caratteristiche dell’infrastruttura;
- architettura delle applicazioni;
- possibilità o meno di reingegnerizzare le applicazioni;
- processi aziendali;
- grado di obsolescenza delle infrastrutture on premises;
- restrizioni normative;
- propensione all’innovazione dell’azienda.
Analisi delle applicazioni
Un possibile approccio, come suggerito da Forbes, è l’analisi delle applicazioni dal punto di vista dei processi, del core business e dell’importanza che esse hanno all’interno dell’azienda.
Questo approccio produce per ciascuna applicazione una modalità di migrazione adeguata al business model aziendale. Le possibilità sono:
- Rehost
- Replatform
- Refactor
- Repurchase
- Retain
- Retire
Vediamo le prime quattro modalità nei paragrafi seguenti. Le ultime due escludono le applicazioni dalla migrazione e rappresentano uno dei passi da compiere in un generale consolidamento applicativo e di risorse che va fatto prima della migrazione.
Rehosting (Lift & Shift)
Le organizzazioni che non hanno propensione/voglia di approcciare una migrazione in termini dirompenti utilizzano la modalità Lift & Shift.
Il rehosting, come viene altrimenti detto, è la semplice migrazione delle virtual machine e delle infrastrutture verso il cloud, senza modificare le applicazioni e i processi, spostando semplicemente il punto di erogazione dei servizi.
Esso implica il “copia e incolla” della infrastruttura on premises fatta di VM e networking virtuale sulla piattaforma messa a disposizione del service provider. Questa operazione potrebbe essere fatta addirittura senza neppure cambiare hypervisor e ha il vantaggio di non modificare architetture e processi che sono già collaudati e ben conosciuti, richiedendo poca o nessuna attività per adattare l’infrastruttura al nuovo ambiente.
Questa modalità ha una serie di pro e contro che vanno valutati e mappati sulle proprie esigenze e possibilità.
Pro:
- Lift & Shift: spesso la migrazione può essere fatta importando direttamente l’immagine di una VM; nel caso peggiore consiste in una reinstallazione con la stessa configurazione di partenza;
- nessuna o poche modifiche: architetture, relazioni e processi rimangono gli stessi;
- veloce da eseguire: la migrazione può essere portata a termine in tempi relativamente brevi;
- facile da eseguire: in funzione dei punti precedenti, non implica un ridisegno né alcun cambiamento nella modalità di erogazione dei servizi.
Contro:
- minore granularità di configurazione: le configurazioni delle VM sulle piattaforme dei provider seguono una logica di “classi” che non permettono la granularità di configurazione concessa da un hypervisor privato. Ne consegue che nel processo di mappatura delle VM verso i nuovi template si può incorrere in un overhead di risorse che potrebbero essere evitato.
- scale-out legato al modello tradizionale: mentre lo scale-up è relativamente semplice agendo sulla configurazione delle VM, lo scale-out non sfrutta appieno le possibilità offerte dal cloud, ma si limita all’aggiunta di nuove VM.
- il mantenimento del modello di erogazione tradizionale non consente di sfruttare appieno le vere potenzialità dei servizi cloud: un Lift & Shift utilizza quasi esclusivamente IaaS e l’impronta su PaaS e SaaS è per forza di cose limitata.
Malgrado queste considerazioni, il rehosting è un’operazione che porta dei vantaggi a medio e lungo termine, sia per tutte le considerazioni già fatte sul TCO di infrastruttura che per la fase di transizione che potrebbe rappresentare: il passaggio in cloud può essere propedeutico all’adozione di un modo più moderno di erogare applicazioni, facendo leva sulla confidenza acquisita progressivamente nella modalità cloud basata su SLO e SLA, e sulla constatazione del fatto che l’ownership dell’infrastruttura è molto meno importante di quanto sembri.
Replatform
Il replatform trasferisce le risorse nel cloud con una piccola quantità di up-versioning, magari utilizzando un’offerta DB gestita o l’aggiunta della scalabilità automatica abilitata all’automazione, per trarre vantaggio dall’infrastruttura cloud. Nonostante un percorso di migrazione più lento rispetto al rehosting, questo approccio offre una solida via di mezzo tra L&S e refactoring, consentendo ai carichi di lavoro di sfruttare la funzionalità di un PaaS e l’ottimizzazione dei costi ma senza il livello di impegno richiesto per il refactoring.
Già una piccola ottimizzazione può portare vantaggi significativi senza modificare l’architettura dell’applicazione principale. Nel replatform si utilizzano per quanto possibile i servizi PaaS senza dover riscrivere tutta l’applicazione, ed è un approccio che consente agli sviluppatori di riutilizzare le risorse con cui sono abituati a lavorare in termini di linguaggi di programmazione legacy e framework di sviluppo.
L’idea è quella di utilizzare PaaS per tutti i servizi “indifferenziati” che non sono il focus aziendale e usano protocolli e risorse standard, come per esempio:
- Identity Management
- servizi di Active directory
- DNS
- istanze database
- networking virtualizzato
- load balancing
- CDN
- HA
- backup
- DR (almeno la parte infrastrutturale)
- tutto ciò che funziona allo stesso modo indipendentemente dalle architetture e dai processi e che viene erogato in PaaS dal cloud pubblico.
Questi servizi stanno diventando commodity con sempre meno valore aggiunto e non diversificano rispetto ai competitor; inoltre non rappresentano il focus dell’attività dell’azienda nella grande maggioranza dei casi. Utilizzare PaaS invece di fare un “copia e incolla” dell’architettura consente di sfruttare tutti i vantaggi del cloud e aumentare scalabilità e affidabilità.
Refactor
Il refactor prevede un processo più avanzato di riscrittura dell’architettura e spesso di ricodifica di parte di un’applicazione esistente per sfruttare i framework e le funzionalità native del cloud. Questo approccio è il più lungo e dispendioso in termini di risorse, ma può offrire canoni più bassi degli altri due approcci. Tramite un refactoring le aziende sono in grado di modificare le proprie applicazioni e infrastrutture per sfruttare appieno le funzionalità native del cloud e massimizzare l’efficienza dei costi operativi nel cloud.
Il modello con il quale si costruiscono le architetture delle applicazioni sta radicalmente cambiando, proprio per la varietà di offerta dei player dei cloud pubblici, sui quali sempre più aziende decidono di spostare i loro carichi di lavoro.
Le strategie dello sviluppo applicativo si stanno orientando dal modello monolitico a quello a microservizi, passando da una struttura applicativa composta da un unico oggetto che contiene ed eroga tutte le funzioni dell’applicazione a una composta da singoli microservizi con un singolo compito definito e interconnessi tra di loro per comporre l’applicazione.
I vantaggi sono diversi:
- I microservizi sono erogati direttamente in PaaS; normalmente basta fornire il codice e il cloud pubblico si occupa del resto;
- semplicità di manutenzione;
- approccio DevOps nativo;
- possibilità di scalare orizzontalmente i singoli microservizi per adattare il carico ed eliminare i colli di bottiglia interni;
- riusabilità del codice: spesso i singoli microservizi possono essere riutilizzati senza modifiche per altre applicazioni.
Ci sono diversi modi di creare microservizi, i tre principali sono:
- host
- container
- serverless
(Per chi fosse interessato ad approfondire l’architettura dei microservizi, consiglio questa eccellente serie di articoli sul blog di nginx)
Come nota a margine, si può immaginare che la tecnologia dei container stia per fare alla virtualizzazione quello che la virtualizzazione ha fatto ai server fisici. La sua forza è l’isolamento di contesti indipendenti dalla piattaforma, il bilanciamento e la scalabilità native, la facilità di deployment, e la possibilità di sviluppare applicazioni senza preoccuparsi delle dipendenze delle librerie. Con poche righe di configurazione si possono avviare degli “sciami” di servizi che si adattano al carico e sono facilmente orchestrabili tramite piattaforme standard.
Repurchase
Il repurchase non è una vera e propria migrazione, ma è piuttosto una transizione verso una modalità di fruizione completamente diversa, sia dal punto di vista tecnologico che operativo. Il mondo consumer è da tempo abituato a utilizzare prodotti SaaS: Gmail, Office 365, Facebook, Twitter, Instagram, sono tutti SaaS; il fatto che molti siano gratuiti non ha implicazioni sulla modalità con cui sono erogati.
Che cosa sia SaaS lo spiega molto chiaramente Microsoft:
“Il modello SaaS offre una soluzione software completa che puoi acquistare con pagamento in base al consumo da un provider di servizi cloud. Noleggi l’uso di un’app per l’organizzazione e gli utenti si connettono all’app tramite Internet, in genere con un Web browser. L’infrastruttura sottostante, il middleware, il software delle app e i dati delle app si trovano tutti nel data center del provider di servizi. Il provider di servizi gestisce l’hardware e il software e, con il contratto di servizio appropriato, garantisce la disponibilità e la sicurezza dell’app e dei dati. Il modello SaaS consente alla tua organizzazione di essere rapidamente operativa con un’app con costi iniziali minimi.”
Quando la sua applicazione è possibile, SaaS è la scelta migliore per evitare tutte le complessità che non sono nel focus del servizio e garantisce una flessibilità senza pari, visto che il suo cost driver è molto spesso il numero di utenti che accedono al servizio.
Quindi
L’efficacia dei cloud pubblici si esprime al meglio tramite i “Servizi Gestiti”, cioè il PaaS e il Saas.
Questo approccio sposta il focus dell’erogazione dalla pura infrastruttura (considerata in termini di risorse computazionali), alla erogazione di applicazioni.
Non si parte dalle virtual machine per arrivare alle applicazioni, ma si isolano le singole applicazioni, se ne analizzano le relazioni e si identificano i servizi adatti a erogare le applicazioni tramite cloud pubblico.
Questo approccio è più difficile e implica un’analisi più profonda, richiede la disponibilità di tutta l’azienda e del supporto applicativo, ma non necessariamente deve essere un processo “one shot”. Anzi, è meglio che la migrazione sia graduale, un ambito alla volta, in modo da approfittare delle possibilità che il cloud concede di “fallire rapidamente” senza gravi conseguenze progredendo nel contempo verso la soluzione ottimale.
