Il fenomeno OpenStack spiegato: cosa fare, cosa non fare

F.L. -

17 Settembre 2013

Il ruolo del project manager It, la matrice, le opzioni, il legacy. Parla Frederik Bijlsma di Red Hat.

Nel giro di poco più di venti anni Linux è passato dall’essere un ideale di opensource a sistema operativo enterprise.
La sua adozione non è stata però lineare: i ritmi di crescita degli ultimi cinque anni hanno superato quelli dei precedenti quindici.

In altre parole, superata la fase romantica è servita la sua commercializzazione perché si creasse la necessaria fiducia e Linux potesse diventare una tecnologia dominante.

Se ne trae che le curve di adozione di una tecnologia variano a dipendenza dei singoli casi. Anche la virtualizzazione ha alle spalle una storia lunga, a dispetto della sua recente espansione nelle grandi aziende. E l’adozione della virtualizzazione opensource è stata ancor più rapida.
Ora ci troviamo al punto di partenza della curva di adozione relativa al cloud.

Gli esempi di adozione a livello enterprise di servizi cloud-based tendono ad essere isolati su soluzioni specifiche, come lo storage. Inoltre, i cloud provider forniscono spesso servizi proprietari, incapaci di parlarsi.
Ecco che l’opensource, per natura, consente di superare questi limiti.
Consideriamo quindi, assieme a Frederik Bijlsma, Emea Cloud Business Unit Manager di Red Hat il tema OpenStack, un progetto di cloud computing opensource guidato dalla OpenStack Foundation per garantire l’erogazione di un’infrastruttura sotto forma di servizio (IaaS).

OpenStack, spiega Bijlsma, offre alle aziende la possibilità di avviare un’implementazione IaaS in modo più efficace dal punto di vista economico.
Uno degli elementi fondamentali è il fatto che i servizi di elaborazione, di rete e storage possono essere forniti sotto forma di software piuttosto che di hardware.

Ma se OpenStack sta maturando in modo veloce, le applicazioni tradizionali non sono ancora del tutto adatte per questa trama.
In questa situazione, si rivela interessante osservare diversi modelli di business emergere attorno ad OpenStack e legare i relativi brand al progetto di cloud opensource.

Le questioni per il team di project management
Ancor prima che un’azienda consideri l’adozione di OpenStack, il team di project management deve avere una visione completa delle sue caratteristiche It, con una matrice dettagliata delle necessità di ogni workload aziendale.

La matrice dovrebbe considerare elementi di base come sicurezza del cloud (regole e normative legate ai dati ed alla privacy), regole di localizzazione (dove si trova l’utente e dove possono essere collocati i dati dal punto di vista normativo), interconnessioni e dipendenze rispetto ad altre applicazioni ed alle relative caratteristiche specifiche, quali architetture di scaling e ad alta disponibilità (può un’applicazione crescere in modo orizzontale, mantenere la sua elevata disponibilità con nodi stateless su tutti i suoi livelli?).

Queste, per Bijlsma, sono le questioni che ogni project manager It dovrà chiarire prima di avvicinarsi ad OpenStack. Ce ne saranno altre, ovviamente, e dipenderanno dal tipo di attività, dall’infrastruttura It esistente, dai budget e dalla cultura tecnologica presente in azienda.

Bijlsma cita un modo di dire: “se si fallisce nel pianificare si pianifica di fallire”, e ciò vale in pieno quando si parla di adozione di OpenStack.

Molte aziende hanno già definito a livello organizzativo matrici tecnologiche nei fatti, perché si tratta di una buona abitudine. Ma sono tante le aziende che non riescono a farlo in modo adeguato o semplicemente ne perdono il controllo, le semplici attività di contabilità o reportistica spesso finiscono in secondo piano, davanti alla priorità di realizzare un progetto o una serie di progetti.

Fare la matrice architetturale
Solo quando lo scenario complessivo è noto un’azienda sarà nella posizione di vedere cosa può essere migrato, cosa deve rimanere su un’infrastruttura di datacenter tradizionale, e come gestire la coesistenza e la migrazione.

Secondo Bijlsma per poter gestire in modo più efficace differenti soluzioni di virtualizzazione/IaaS, potrebbe essere utile considerare una soluzione software per la “gestione dei gestori”, come Red Hat CloudForms, per implementare in modo continuo i processi di business di un’organizzazione.
Questo si lega alla creazione di una matrice architetturale di building block. Con una vista delle applicazioni che possono essere migrate, il livello appropriato di risorse necessarie può essere stimato più accuratamente.

The legacy remains the same
Da un punto di vista pragmatico i project manager devono accettare il fatto che, nonostante la decisione di abbracciare OpenStack i sistemi legacy non possono essere dimenticati.
Una volta che sono state prese le decisioni su cosa può e cosa non può essere migrato, e che l’azienda si trova sul punto di avviare il percorso verso OpenStack, lo step successivo dovrebbe essere rappresentato da una valutazione dei modelli di business proposti dai vendor.
Gli utenti si troveranno di fronte a una quantità sorprendente di possibilità.
Secondo Bijlsma alcuni vendor guarderanno ad OpenStack come una soluzione open che porta con sé tutti i vantaggi dell’opensource. Altri venderanno un OpenStack modificato per connettersi alle soluzioni proprietarie: sarà OpenStack nel nome ma non nello spirito, andando nei fatti a legare ulteriormente il cliente alle soluzioni legacy.

Legata alla selezione di un modello di business è la scelta di un partner in grado di capire le proprie necessità, sia a livello di business che tecnologiche.
Per certi progetti, la tecnologia dovrebbe essere compresa in modo approfondito, e parallelamente dovrebbero essere definite in anticipo aspettative relative a “cosa, quando e quanto”.

Cosa migrare
In sintesi, per Bijlsma, partner fidati possono aiutare in questo, e possono permettere alle aziende di lanciarsi velocemente su questi progetti.

In generale, non sarà possibile o opportuno migrare l’intero patrimonio It di un’azienda ad OpenStack.
Per questo, gestire componenti legacy resterà una problematica continua, soprattutto perché questi sistemi con ogni probabilità evolveranno nel tempo e richiederanno livelli aggiuntivi di management.
Venti anni fa, in molti preconizzavano la fine del mainframe, sbagliando.
Lo stesso per Bijlsma accadrà per ogni sistema che non verrà trasferito nel cloud con OpenStack.

Come fare
È importante ricordare che OpenStack può essere utilizzato sotto forma di servizio supportato, e che non si tratta necessariamente di un’installazione one-off.
Piuttosto che investire in un roll out personalizzato, che risulterebbe costoso in sé, l’azienda si troverebbe ad affrontare costi relativi ad una gestione e manutenzione continue. Utilizzare OpenStack con un modello di sottoscrizione completamente aperto eviterà il vendor lock-in, se questo non dipenderà da strumenti closed-source inclusi nell’offerta.
In particolare, task come patching, rimedi di sicurezza ed aggiornamenti di versione possono essere affrontati scegliendo un package supportato.

In estrema sintesi: piuttosto che ripartire da zero, la gestione delle configurazioni e del ciclo di vita di OpenStack possono e dovrebbero essere realizzate in modo simile alla distribuzione Linux enterprise esistente in azienda.