Ricetta Semplice per il Successo con gli Impegni OpenStack

2016-06-09

Machine-translated — the English original is authoritative.

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!

Originally published on allthingscloud.eu (2016-06-09).