Recette simple pour réussir vos projets OpenStack

2016-06-09

Machine-translated — the English original is authoritative.

Un client m’a récemment demandé quelle était, à mon avis, la meilleure recette pour réussir une installation OpenStack ? Avec 20 ans d’expérience dans les déploiements de centres de données (matériels et logiciels), je peux honnêtement dire que ma réponse a peu changé au fil du temps. Ce sont toujours les bases qui sont négligées.

J’ai passé les deux dernières années à déployer Helion OpenStack à travers le monde, dans des banques, des entreprises pharmaceutiques et des détaillants, et le post suivant met en lumière ce que je crois être les ingrédients d’un déploiement OpenStack réussi (ou de toute autre plateforme cloud, d’ailleurs).

Parties prenantes – Sponsoring exécutif

PersonnesProcessusTechnologie

Il est vital, lors du déploiement d’une solution cloud qui traversera de nombreux départements (a.k.a. silos) comme le réseau, le stockage, la sécurité, etc., que le projet dispose d’un sponsor actif et impliqué qui se situe au sommet de tous ces silos. Idéalement, le DSI, le Directeur des Opérations et le responsable des ressources humaines devraient être impliqués pour élaborer une stratégie claire visant à examiner comment cette nouvelle technologie aura un impact sur leurs processus et leur personnel actuels. Afin de tirer véritablement parti des avantages offerts à une entreprise par la transition vers un modèle cloud, ces processus devront changer de manière drastique au sein de l’entreprise.

Malheureusement, ce qui se produit souvent, c’est qu’un seul des silos achète la solution et pense qu’il devrait tout posséder. Ils échoueront ! La technologie est la partie facile – les personnes et les processus sont ce qui compte.

Ce qui devrait se produire, et encore une fois, ce n’est que mon opinion personnelle, est la création d’équipes virtuelles issues de tous les silos. Formez ces personnes à l’ensemble de la solution en les maintenant concentrées sur leur domaine d’expertise (SME). Il ne devrait pas leur falloir longtemps pour voir les avantages du travail en commun et, espérons-le, réaliser le potentiel d’OpenStack en même temps. C’est aussi une bonne étape dans la direction d’un modèle d’exploitation d’intégration continue et de déploiement continu (osei-je dire DevOps). Bien que nous couvrions initialement les silos au sein des équipes d’exploitation, le processus est très similaire pour intégrer les développeurs. Ces personnes ont tendance à être très enthousiastes à propos du modèle d’exploitation cloud car elles ont été gâtées par AWS au cours des 5 dernières années… l’IT fantôme, c’est une autre histoire !

Confusion sur l’Open Source – Périmètre réaliste

opensourceConfusion.fw

Croyez-le ou non, à plus d’une occasion au cours des deux dernières années lors d’installations OpenStack, j’ai eu des clients qui cherchaient leur stockage « Ceph » ou leurs conteneurs « Docker », sans se rendre compte que ceux-ci ne font pas partie d’OpenStack natif mais sont des produits entièrement différents en soi. Il est très important de tenir un atelier cloud avec les clients tôt dans le cycle d’engagement [ce qui devrait être avant que l’équipe commerciale n’ait installé du matériel sur site] et d’examiner leurs exigences fondamentales – encore une fois, comme mentionné plus tôt – il faut revenir aux bases. Ne vous contentez pas d’explorer les exigences IaaS, cherchez les exigences commerciales ultimes. Il y aura des moments où OpenStack ne pourra pas répondre aux exigences d’un client, ou où des fonctionnalités sont encore expérimentales – assurez-vous que le client comprend cela. Expliquez comment fonctionne la communauté OpenStack, les releases tous les 6 mois, le processus de soumission de blueprint, etc. Cet atelier est également votre chance de déterminer quelles parties prenantes manquent et de chercher leur implication.

Pierre, Feuille, Ciseaux, VMware

Si le client est déterminé à se débarrasser de VMware et pense qu’OpenStack est la solution, marchez avec beaucoup de précaution. VMware propose un hyperviseur très bon et puissant, avec beaucoup plus de fonctionnalités de haute disponibilité que celles disponibles avec l’hyperviseur KVM par défaut. Il n’y a aucune raison aujourd’hui de ne pas pouvoir avoir les deux types d’hyperviseur au sein d’un cloud OpenStack – j’ai essayé cette fonctionnalité avec Helion OpenStack 3.0 et cela fonctionne très bien.

Écoutez très attentivement les attentes du client – s’ils mentionnent des choses comme des économies de coûts ou un simple déplacement (« lift and shift ») d’applications – fuyez maintenant. Cependant, s’ils parlent d’applications cloud natives et de programmes de transformation pour traiter leurs applications héritées, alors oui – c’est la bonne mentalité.

Pénurie de compétences OpenStack

Essayer de trouver des ingénieurs OpenStack expérimentés, c’est comme…..

Bien que cette pénurie de compétences puisse être de courte durée, (compte tenu du taux d’adoption actuel des clouds OpenStack), c’est une préoccupation réelle pour de nombreux clients. Cependant, il existe deux moyens très simples de relever ce défi :

Option 1

Cessez de vous limiter à la recherche de personnes ayant des compétences OpenStack – un bon administrateur Linux apprendra OpenStack avec une formation minimale. S’ils se débrouillent bien sous Linux (y compris les namespaces réseau), ont une compréhension de base des bases de données et des files de messages, alors OpenStack sera un jeu d’enfant. [Note aux sociétés de recrutement : La même déclaration pourrait être utilisée pour l’ingénieur DevOps « unicorne » (terme technique)]. Ne vous attendez pas à ce qu’un opérateur OpenStack soit un développeur – ils ne devraient pas l’être !

Option 2

Trois mots – Cloud Privé Géré. De nombreuses entreprises proposent ce service, y compris HPE. Si vous passez au cloud natif et que le PaaS est ce dont vous avez vraiment besoin, pourquoi ne pas externaliser votre cloud privé dès maintenant ?

Commencez par le PaaS – OpenStack suivra

Lorsque nous achetons une voiture, nous n’achetons pas d’abord le moteur, suivi du châssis, de l’intérieur, etc., jusqu’à ce que nous ayons enfin assez de composants pour permettre de conduire de A à B – la directive principale pour l’achat de la voiture.

Alors cela me confond aujourd’hui pourquoi nous semblons obsédés par l’achat d’une solution IaaS en premier, puis en essayant d’adapter une solution PaaS par-dessus. Je crois que les clients devraient commencer par leurs exigences PaaS. C’est généralement là que se trouvent les développeurs, les véritables exigences commerciales et l’argent.

Pas seulement cela, mais les clients peuvent essayer la plupart des plateformes PaaS aujourd’hui sans jamais avoir à acheter un seul morceau de matériel. Une fois que l’entreprise et les développeurs savent ce dont ils ont besoin d’une solution PaaS, il est beaucoup plus facile de s’assurer que l’IaaS sous-jacent est adapté à l’usage prévu.

Conclusion

Pour réussir dans un projet OpenStack n’est pas différent de tout autre projet informatique. Une fois que vous pouvez cocher la liste de contrôle suivante, tout le reste devrait être une affaire courante –

• Personnes
• Processus
• Technologie

Comme je l’ai dit – rien de nouveau ici – les mêmes ingrédients étaient nécessaires il y a 20, 30 et 40 ans.

Il est également fondamental que tout le monde comprenne la différence entre les styles d’application Cloud Native et Traditionnels. [Un signe révélateur que quelqu’un ne comprend pas ces principes est lorsqu’il essaie de comparer VMware à OpenStack.]

Enfin, j’ai trouvé les trois livres suivants très utiles pour illustrer certains des concepts de base autour des équipes virtuelles, du cloud natif et du devops :

• The Phoenix Project
• Continuous Delivery
• The Mythical Man-Month

Merci, Happy Stacking !

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