Huit bonnes raisons de ne pas utiliser OpenStack

OpenStack a le vent en poupe et alimente toutes les discussions. OpenStack empiéterait sur les plates-bandes de la virtualisation et du cloud public. Cela ne signifie pas pour autant que vous deviez céder. Si toutes les autres entreprises sautaient d’un pont, sauteriez-vous aussi ? Bien sûr que non.

Dépendre d’un vendeur ne vous gêne pas plus que cela.

Vous comprenez l’intérêt de la virtualisation parce que vous tenez à maximiser l’utilisation des ressources de vos équipements ; vous êtes donc prêt à mettre le prix. Mais que se passe-t-il si le logiciel ne fait pas ce que vous attendez de lui ? Les éditeurs de logiciels sont des professionnels. S’ils n’ont pas jugé utile d’intégrer une fonction, c’est que vous n’en avez pas besoin.

 

OpenStack est en revanche une solution Open Source, ce qui, dans le contexte qui nous intéresse, signifie plusieurs choses :

Si vous souhaitez ou avez besoin d’une fonction qui n’est pas disponible, vous pouvez tout simplement la créer vous-même, ou confier son développement à une tierce personne. Vous n’êtes pas pieds et poings liés avec un éditeur ou sa feuille de route.

Si vous n’aimez pas votre éditeur OpenStack actuel, vous pouvez en changer sans modifier la manière dont vous interagissez avec vos systèmes. Seule condition : ne pas dépendre d’extensions propriétaires susceptibles d’avoir été ajoutées par cet éditeur.

 

Payer des frais qui augmentent au fur et à mesure que vous vous développez ne vous gêne pas plus que cela.

Ces frais n’ont pas d’effet dissuasif sur votre développement. Une entreprise coûte de l’argent. Il vous semble normal de payer plus pour développer votre entreprise. Mais qu’en est-il si les frais engagés concernent des ressources qui ne vous rapportent pas encore, comme les blocs de licences de machines virtuelles (VM) ou les serveurs de cloud public uniquement utilisés pour le développement ou les tests ? C’est le prix à payer pour faire des affaires.

D’un autre côté, OpenStack n’étant adossé à aucun modèle de tarification des licences par CPU, vous pouvez monter ou démonter le nombre de machines virtuelles souhaité dans votre cloud privé, comme bon vous semble, sans vous préoccuper des questions de licences.

Vous n’avez pas besoin d’avancer plus vite.

Vous n’avez aucun concurrent et quand bien même, votre avance est telle, que vous n’avez pas besoin de sortir vos produits et vos solutions plus vite qu’actuellement. Vos clients ? C’est à eux d’attendre que vous soyez prêts à leur fournir quelque chose. Ce n’est pas comme s’ils allaient passer à la concurrence.

 

D’un autre côté, avec une infrastructure en tant que service (IaaS), vos développeurs peuvent installer un serveur opérationnel en deux temps trois mouvements. Dès qu’une idée ou une requête survient, ils peuvent intervenir en quelques minutes, et non en plusieurs semaines, voire plusieurs mois. C’est d’autant plus vrai si vous possédez votre propre cloud OpenStack, car cela leur évitera de faire chauffer la carte bleue.

 

La performance et la disponibilité ne sont pas un souci pour vous.

Vous utilisez le cloud public parce que vous ne souhaitez pas avoir à vous préoccuper de choses aussi triviales que le temps de fonctionnement (uptime) et la disponibilité. Le fait que votre application partage un serveur avec quelqu’un d’autre ne vous pose aucun problème. Quant aux risques de sécurité, ils ne vous inquiètent pas le moins du monde. Qui cela gêne-t-il que votre application rame à mort lors de l’exécution d’une tâche importante ? L’application reste disponible, non ? Ce n’est pas le cas ? Elle sera à nouveau disponible plus tard, c’est le problème du fournisseur de cloud public, pas le vôtre.

Avec le Cloud privé, vous n’avez pas à vous soucier d’avoir à partager vos ressources avec une personne ou une entreprise prise au hasard. Mais malgré cela, il faut veiller à ce que tout fonctionne. En revanche, avec OpenStack, le cloud privé géré – également connu sous le nom de cloud privé en tant que service – constitue une alternative intéressante : le fournisseur est responsable du temps de fonctionnement et vous bénéficiez de tous les avantages du cloud privé.

Vous n’avez pas envie de changer.
Cela fait longtemps que vous créez vos applications ainsi, et vous n’avez pas la moindre intention de vous plonger la tête dans ce nouveau truc à la mode : le cloud. Des machines comparées à des animaux domestiques ou du bétail ? Des applications qui continuent à fonctionner même en cas de panne serveur ? C’est insensé. Qui voudrait d’un truc pareil ? Non merci, vous vous en tiendrez au bon vieux modèle fiable du client/serveur. Et s’il arrive quelque chose à un serveur, vous vous en occuperez et mettrez tout en œuvre pour le remettre d’aplomb.

D’un autre côté, OpenStack vous offre la possibilité – sans vous l’imposer – d’accéder au monde des applications résilientes. Si vous souhaitez accélérer le montage d’une machine virtuelle et abandonner l'une de ses bases de données client/serveur, c’est parfaitement envisageable. Vous pouvez également profiter d’une architecture qui vous permet simplement d’éteindre une machine qui ne fonctionne pas pour la remonter ailleurs sans que vos utilisateurs s’en aperçoivent.

Vos collaborateurs ne sont pas encore prêts.

Vos collaborateurs ont leurs habitudes. Ils aiment les choses comme elles sont et n’ont aucune envie d’adopter les principes du cloud. Si tel était le cas, ils auraient déjà pris congé. S’ils partent pour de nouveaux horizons qui leur offrent de nouveaux défis à relever, l’occasion d’acquérir de nouvelles compétences et de valoriser leur expérience sur le marché, et bien bon débarras. De toute façon, vous n’avez besoin d’aucun précurseur ou visionnaire dans votre équipe.

 

D’un autre côté, OpenStack offre à votre équipe informatique l’occasion de participer à la nouvelle vague informatique sans vous quitter avec, en prime, leur expérience de vos processus métier et de produits. L’époque où la DSI représentait le plus gros frein au changement est en passe de disparaître. Les professionnels savent dans quelle direction la technologie évolue et souhaitent en être.

 Vous n’avez pas besoin de « DevOps ».

Vos responsables d’exploitation occupent une place spéciale et leur mission l’est tout autant. Ils préféreront toujours effectuer leur travail "à la main" plutôt que de rédiger des scripts ou de standardiser certains processus pour mieux les reproduire et les documenter. Après tout, qui voudrait en savoir autant sur le fonctionnement d’un système ?

D’un autre côté, OpenStack  vous permet de transformer le pôle Exploitation de votre DSI en une machine bien huilée où les tâches sont non seulement fiables et reproductibles, mais bénéficient en prime d’un système de contrôle des versions. En termes de visibilité sur l’activité, les avantages sont indéniables. Mais point le plus important : vos exploitants peuvent se concentrer davantage sur leur mission de service au sein de votre organisation. Dégagés des tâches d’exploitation pures (comme les centaines d’installations de serveurs par semaine), ils peuvent ainsi consacrer plus de temps à mener une réflexion globale (et à concevoir).

Vous n’aurez jamais besoin de capacités supplémentaires.

L’idée de pouvoir booster ses capacités dans le cloud à la demande est tout simplement ridicule. Vous conserverez toutes les capacités dont vous pourriez avoir besoin sous la main, dans votre centre de données. Mais, que se passe-t-il si ces capacités restent inutilisées 95% du temps ? C’est une charge d’exploitation que vous pouvez déduire de vos impôts, au même titre que toutes les dépenses d’électricité, de refroidissement, de fonctionnement et tout ce dont vous avez besoin pour maintenir vos systèmes à ne rien faire.

D’un autre côté, OpenStack  vous permet de garder sous la main uniquement les ressources dont vous êtes certain d’avoir besoin – ou que vous devez conserver en interne pour des questions de sécurité ou des raisons réglementaires. Si vous avez besoin de capacités supplémentaires pour absorber les pics d’activité, vous pouvez toujours recourir au débordement de charge (cloud bursting) vers un cloud privé en tant que service plutôt qu’un cloud public ; vous conservez ainsi tous les atouts d’OpenStack en bénéficiant des avantages du cloud hybride.

Mais au final, peut-être que vous souhaitez VRAIMENT migrer vers OpenStack. Comment cela se passe-t-il ?
En général, la procédure est la suivante :

Décidez de ce que vous souhaitez faire. Comme pour n’importe quel projet informatique, il faut une orientation claire pour ne pas avancer dans le brouillard.

Commencez modestement avant d’évoluer. Abordez votre projet en créant un proof of concept pour un petit cloud qui permettra aux utilisateurs et développeurs de se faire une idée. Vous pouvez effectivement télécharger directement OpenStack et le mettre en œuvre vous même. Mais à moins que vos équipes soient suffisamment expérimentées, mieux vaut commencer avec l’une des nombreuses distributions disponibles.


Mettez dans la boucle un fournisseur capable de vous épauler.
Il n’y a rien de mal à vouloir faire grossir votre cloud de manière organique, mais dès lors que vous dépasserez le stade de proof of concept pour entrer dans les phases de pilote et d’implémentation de plus grande envergure, n’hésitez pas à faire appel à un fournisseur qui maîtrise les implications architecturales et puisse vous guider. Cela vous évitera plus tard bien des tourments (et vous fera économiser de l’argent).

Procédez à des réévaluations à intervalles réguliers.

Vos collaborateurs vont devoir s’adapter et s’habituer au cloud pour commencer à en exploiter toutes les possibilités. Évaluez régulièrement la situation pour vous assurer que vous répondez à leurs besoins en cours et réfléchir aux axes d’amélioration.

Il n’est jamais simple de changer, mais au final, les changements bien pensés, comme une évolution vers OpenStack, finissent toujours par payer et valent largement le temps et les efforts investis.



Auteur : David Fishman, Vice-président marketing, Mirantis