Fournir une VM sur étagère via un portail de self-service est une tâche techniquement accessible. Pourtant, peu de projets de cloud privé sont de vrais et francs succès. Nous allons essayer de comprendre les raisons de ces succès partiels.
L'obtention d'une VM seule en moins de 10 minutes apporte rarement de la valeur aux utilisateurs. En effet, quel est le gain opérationnel s'il faut encore attendre 5 semaines pour la rendre fonctionnelle avec la résolution DNS, les ouvertures réseaux et les accès utilisateurs ?
L'exemple précédent montre bien que la réelle valeur ajoutée est de pouvoir utiliser la machine. Cela implique donc, en plus de fournir des VM, d'automatiser (et donc potentiellement virtualiser) d'autres pans du Système d’Information. Par expérience, ceci peut d'ailleurs, au fur et à mesure des exigences des utilisateurs, toucher de proche en proche une grande part des services d'infrastructure.
Le pilotage par la valeur est d'autant plus important qu'un bon projet piloté uniquement par l'aspect technique peut finalement s'avérer contre-productif. J'ai participé à un projet de cloud privé dans une grande assurance française, dont le but était de mutualiser des infrastructures de calcul. Le principe consistait à provisionner et décommissionner automatiquement et en temps réel des machines en fonctions des besoins des actuaires. La plateforme fonctionnait tellement bien et de manière si transparente que les actuaires l'utilisaient sans se soucier de l’allocation des ressources. Il en a résulté une hausse de la facture globale, alors que le projet avait été initié pour justement baisser cette facture par la mutualisation de l'infrastructure.
Si ce projet avait été piloté par la valeur, la question du contrôle des dépenses serait naturellement venue sur la table. Il est évident que les processus de décision sont différents quand on peut provisionner des ressources en temps réel de quand on met 6 mois pour les obtenir.
La mise en place d'un cloud implique aussi de nouveaux usages. Typiquement, par simplicité, on préfèrera :
- Lancer une nouvelle VM et lui appliquer une configuration existante plutôt que de redémarrer et diagnostiquer une VM crashée
- Lancer une VM avec la dernière image disponible plutôt que de patcher une VM existante
- Adapter le nombre de VM en temps réel plutôt que de dimensionner l’infrastructure pour absorber les pics d’activité
À travers ces nouveaux usages, c'est la culture de l'automatisation que l'on propage jusqu'aux utilisateurs de la plateforme.
Il est aussi important d’avoir une plateforme fiable permettant de répondre à ces nouveaux usages. Dans une de mes expériences pour une grande banque française, j'ai pu constater que la mise en place d'un cloud privé facilitait réellement le provisionnement de VM. Par contre, le service ne fournissait les VM que dans 70% du temps à cause de soucis de stabilité de la plateforme. En conséquence, les développeurs souhaitaient rarement prendre le risque de supprimer leurs VM et les dimensionnaient en fonction des pics de charge de leurs applications. Au final les utilisateurs de la plateforme de cloud n'était pas mécontent : ils obtenaient des VM plus rapidement qu’auparavant. Mais la qualité de la plateforme n'étant pas au rendez-vous, c'était la triple peine pour la DSI :
- Elle n'obtenait pas les ROI escomptés du fait du surdimensionnement des infrastructures
- Elle accumulait une dette technique importante, car trop de ressources étaient utilisées pour le support et l'expansion de la plateforme
- Elle dégradait son image en raison de la mauvaise qualité du service
Que ce soit en termes de valeur ou d'usage, les impacts de la mise en place d'un simple portail de self-service de VM se révèle important. Pour en avoir tous les fruits, il est primordial d'intégrer la démarche technique de création d'un cloud privé dans une démarche plus complète de transformation DevOps de la DSI. Cette transformation demandera, en plus des changements techniques, des changements culturels, organisationnels et méthodologiques.
