Un cliente mi ha chiesto recentemente quale, secondo me, fosse la ricetta migliore per un'installazione di OpenStack di successo? Con 20 anni di esperienza nei deployment di data center (hardware e software) posso dire onestamente che la mia risposta è cambiata ben poco nel tempo. Sono ancora le basi a essere trascurate.
Ho trascorso i due anni passati a distribuire Helion OpenStack in tutto il mondo in banche, aziende farmaceutiche e dettaglianti, e il seguente post evidenzia ciò che ritengo siano gli ingredienti per un deployment di OpenStack di successo (o di qualsiasi altra piattaforma cloud, del resto).
Stakeholder – Patrocinio Esecutivo
PersoneProcessoTecnologia
È fondamentale, quando si distribuisce una soluzione cloud che attraverserà molti dipartimenti (a.k.a. silos) come networking, storage, sicurezza, ecc., che il progetto abbia un sponsor Attivo/Impegnato che si trovi al vertice di tutti questi silos. Idealmente, il CIO, il COO e il capo delle Risorse Umane dovrebbero essere coinvolti per sviluppare una strategia chiara volta a rivedere come questa nuova tecnologia impatterà sui loro processi e sul personale attuali. Al fine di sfruttare appieno i benefici che il passaggio a un modello cloud offre a un'azienda, questi processi dovranno cambiare drasticamente all'interno dell'impresa.
Purtroppo, ciò che tende a succedere è che solo uno dei silos acquista la soluzione e pensa di doverla possedere tutta. Falliranno! La tecnologia è la parte facile: persone e processo sono ciò che conta.
Ciò che dovrebbe accadere, e ancora una volta questa è solo la mia opinione personale, è la creazione di team virtuali provenienti da tutti i silos. Formare queste persone sull'intera soluzione mantenendole focalizzate sulla loro area di SME (saperi specifici). Non dovrebbe volerci molto perché vedano i benefici del lavorare insieme e, si spera, realizzino allo stesso tempo il potenziale di OpenStack. È anche un buon passo avanti nella direzione di un modello operativo di integrazione continua e deployment continuo (oserei dire DevOps). Sebbene inizialmente stiamo coprendo i silos all'interno dei team operativi, è un processo molto simile per coinvolgere gli sviluppatori. Queste persone tendono a essere molto entusiaste del modello operativo cloud poiché sono state viziati da AWS negli ultimi 5 anni... shadow IT, questa è un'altra storia!
Confusione Open Source – Ambito Realistico
opensourceConfusion.fw
Credeteci o no, più di una volta negli ultimi due anni durante installazioni di OpenStack ho avuto clienti che cercavano il loro storage "Ceph" o i loro container "Docker" senza rendersi conto che questi non fanno parte di OpenStack nativo ma sono prodotti completamente diversi di per sé. È molto importante tenere un workshop cloud con i clienti all'inizio del ciclo di impegno [che dovrebbe avvenire prima che il team di vendita abbia installato qualsiasi hardware in loco] e rivedere i loro requisiti fondamentali: di nuovo, come menzionato in precedenza, si torna alle basi. Non limitatevi a sondare i requisiti IaaS, cercate i requisiti aziendali ultimi. Ci saranno momenti in cui OpenStack non potrà soddisfare i requisiti di un cliente, o le funzionalità sono ancora sperimentali: assicuratevi che il cliente lo comprenda. Spiegate come funziona la comunità OpenStack, i rilasci ogni 6 mesi, il processo di sottomissione dei blueprint e così via. Questo workshop è anche la vostra opportunità per determinare quali stakeholder mancano e cercare il loro coinvolgimento.
Sasso, Carta, Forbice, VMware
Se il cliente è determinato a liberarsi di VMware e pensa che OpenStack sia la soluzione, procedete con molta cautela. VMware offre un iper-visor molto buono e potente con molte più funzionalità di alta disponibilità rispetto all'iper-visor KVM predefinito. Non c'è motivo oggi per cui non si possano avere entrambi i tipi di iper-visor all'interno di un cloud OpenStack: ho provato questa funzionalità con Helion OpenStack 3.0 e funziona molto bene.
Ascoltate con molta attenzione le aspettative del cliente: se menzionano cose come il risparmio sui costi o il puro lift and shift (spostamento) delle applicazioni, scappate subito. Tuttavia, se parlano di applicazioni cloud native e programmi di trasformazione per affrontare le loro applicazioni legacy, allora sì, questo è il mindset corretto.
Carenza di Competenze OpenStack
Cercare ingegneri OpenStack esperti è come.....
Sebbene questa carenza di competenze possa essere di breve durata (con l'attuale tasso di adozione dei cloud OpenStack), è una preoccupazione reale per molti clienti. Tuttavia, ci sono due modi molto semplici per affrontare questa sfida:
Opzione 1
Smettete di limitarvi a cercare persone con competenze OpenStack: un buon amministratore Linux imparerà OpenStack con una formazione minima. Se sanno muoversi bene in Linux (inclusi i namespace di rete), hanno una comprensione di base dei database e delle code di messaggi, allora OpenStack sarà un gioco da ragazzi. [Nota per le agenzie di reclutamento: La stessa affermazione potrebbe essere usata per l'ingegnere DevOps "unicorno" (termine tecnico)]. Non aspettatevi che un operatore OpenStack sia uno sviluppatore: non dovrebbe esserlo!
Opzione 2
Tre parole: Cloud Privato Gestito. Molte aziende offrono questo servizio, tra cui HPE. Se state andando verso il cloud native e il PaaS è ciò di cui avete davvero bisogno, perché non esternalizzare il vostro cloud privato ora?
Partire con il PaaS – OpenStack seguirà
Quando acquistiamo un'auto, non compriamo prima il motore, seguito dal telaio, dall'interno e così via, fino ad avere abbastanza componenti per facilitare la guida da A a B – la direttiva primaria per l'acquisto dell'auto.
Quindi mi confonde oggi il motivo per cui sembra che siamo ossessionati dall'acquistare prima una soluzione IaaS e poi cercare di adattare una soluzione PaaS sopra di essa. Credo che i clienti dovrebbero iniziare con i loro requisiti PaaS. Di solito è lì che si trovano gli sviluppatori, i veri requisiti aziendali e i soldi.
E non solo: i clienti possono fare un test drive (boom, boom) della maggior parte delle piattaforme PaaS oggi senza dover acquistare nemmeno un singolo pezzo di hardware. Una volta che il business e gli sviluppatori sanno cosa hanno bisogno da una soluzione PaaS, è molto più facile assicurarsi che l'IaaS sottostante sia adatto allo scopo.
Conclusione
Per avere successo in un impegno OpenStack non è diverso da qualsiasi altro progetto IT. Una volta che si possono spuntare le seguenti voci della checklist, tutto il resto dovrebbe essere la solita routine aziendale –
- Persone
- Processo
- Tecnologia
Come ho detto: nulla di nuovo qui: gli stessi ingredienti erano richiesti 20, 30 e 40 anni fa.
È anche fondamentale che tutti comprendano la differenza tra stili di applicazione Cloud Native e Tradizionali. [Un segno rivelatore che qualcuno non comprende questi principi è quando cerca di confrontare VMware con OpenStack.]
Infine, ho trovato i seguenti tre libri molto utili per illustrare alcuni dei concetti di base sui team virtuali, cloud native e devops:
- The Phoenix Project
- Continuous Delivery
- The Mythical Man-Month
Grazie, Happy Stacking!