Ti ho promesso che ti avrei rivelato l’ingrediente segreto per un progetto vincente con OpenStack. Lasciami cominciare con due esempi.

Il primo riguarda un provider di tele-comunicazioni europeo piuttosto conosciuto. Come ogni altro operatore, questi ha una struttura interna complessa e quando qualcuno del team interno propose OpenStack come possibile soluzione, il management ai piani alti decise che non era abbastanza “enterprise” e preferì adottare una soluzione certificata che includeva, fra gli altri, VMware ed Oracle.
Il tempo necessario a fare il deployment di una singola macchina virtuale era circa di 40 giorni a causa di tutti i processi necessari. Un sistemista riceveva ogni giorno delle lamentele dagli sviluppatori, che a loro volta erano sotto pressione dal team di marketing per creare più velocemente le campagne per il mercato.

Questa persona decise di formare un “team non ufficiale” di persone particolarmente competenti, prese alcune vecchie macchine non più usate e creò un cluster con OpenStack in due regioni. Organizzò dei meetup interni per istruire gli sviluppatori e gli interni su come abbracciare la filosofia di OpenStack e come un’applicazione potesse sfruttare la piattaforma sottostante per avere più elasticità e scalabilità.

Questo esperimento non ufficiale ebbe un successo inaspettato e la maggior parte delle nuove applicazioni venne sviluppata su questa nuova piattaforma. Sebbene questo ha scavalcato le regole e le norme interne, il management non poté far altro che prender atto dello status-quo creato e approvarlo ufficialmente.
Quel sistemista è ora il leader di questo gruppo composto solo da 11 persone e che gestisce il 50% delle applicazioni interne della compagnia.

La seconda storia che voglio condividere riguarda un istituto finanziario americano.
A seguito di una conversazione con il CEO di un vendor prestigioso, il CTO di questa banca decise di sposare OpenStack a discapito di VMware. Chiese al suo management di eseguire la transizione. L’ufficio in carica delle architetture IT dovette rivedere tutti i processi in atto e parlare con con i repartidella compagnia. Come molte grandi aziende, anche questa era suddivisa in vari reparti(network, sicurezza, sistemisti, middleware, ecc) a nei mesi successivi ci fu un gran numero di meeting. Il deployment di OpenStack durò 8 mesi usando le policy in uso e seguendo gli standard e le best practices disponibili.

Nonostante tutti gli sforzi, il processo di consegna di un’applicazione scese da 90 a solo 75 giorni. OpenStack funzionava perfettamente, eppure il management non riusciva a capire cosa era andato storto e non poté giustificare in alcun modo l’investimento deciso dal CTO.

Qual è la morale di queste due storie? La realtà è che OpenStack è solamente una tecnologia, e solo lo sposare la sua filosofia permette di ottenere risultati migliori.
Ciò richiede che una compagnia riveda profondamente l’organizzazione dell’IT interno che diventi più produttive e con una approccio AGILE.
Se non sei disposto a cambiare i processi interni e i repartidella tua azienda, non godrai dei vantaggi di OpenStack.
Se rifletti sull’esempio della compagnia di telecomunicazioni noterai che questa ebbe successo perché all’inizio nessuno credette al progetto, in tal modo i sistemisti furono in grado di scavalcare gli schemi e le politiche interne.
Questo approccio, con un programma di consapevolezza interno, rese il progetto un enorme successo.

Naturalmente non è tutto o bianco o nero, ci sono varie sfumature di grigio nel mezzo e non tutte le compagnie sono create allo stesso modo.
Spero di averti dato i mezzi necessari per avere un’idea chiara e vendor-neutral di cosa sia il Cloud e quali benefici può portare, ma anche che devi essere tu a trovare la ricetta per avere successo con OpenStack.