J’ai été invité cette semaine à un évènement comportant des tables rondes entre utilisateurs sur les thèmes du Cloud et de la virtualisation.

J’ai non seulement appris beaucoup de choses, mais surtout découvert la vision du monde de la production et de l’exploitation sur … la qualité des applications.

Avis aux équipes de développement: mangez votre pain blanc tant qu’il est encore temps.

Comme vous le savez probablement, la raison première pour laquelle les entreprises passent d’une infrastructure physique à une infrastructure virtuelle réside dans la réduction des coûts. Vous n’imaginez pas le nombre de serveurs, dans toute organisation, qui n’utilise pas 5% de sa CPU. Cette sous-utilisation représente très fréquemment entre 20% et 40% des infrastructures. Le calcul est simple : si vous décidez d’utiliser moins de 50% des ressources CPU existantes afin de garder de la capacité pour gérer les pics d’utilisation ou mettre en place une politique de HA (High Availability ou Haute disponibilité), un gain de la moitié de la capacité sur 20% ou 40% des machines représente une réduction potentielle de 10% à 20% des achats futurs.

Par contre, cette évolution s’accompagne d’une plus grande complexité pour les équipes de production :

• La plupart des entreprises parviennent à virtualiser 50% de leur parc de serveurs, 80% rarement, personne n’est à 100% virtuel.
• La rationalisation n’est pas à l’ordre du jour : s’équiper de serveurs d’un unique constructeur, des mêmes systèmes virtuels ou OS serait un moyen de limiter les charges de fonctionnement. Mais les directions informatiques préfèrent mettre en compétition constructeurs et éditeurs logiciels afin de faire baisser les coûts.

La virtualisation s’accompagne donc d’une hétérogénéisation très forte des infrastructures, physiques et virtuelles, et crée des silos technologiques hardware / software qui nécessite une spécialisation très importante des équipes de production. Aucun ingénieur système n’est capable de maîtriser l’ensemble du parc et de résoudre tous les incidents qui peuvent survenir.

Parallèlement, la virtualisation s’accompagne d’une exigence de service plus élevée :

• Auparavant, si vous aviez besoin d’un nouveau serveur pour un nouveau projet, la réponse était : « Dans 1 mois, le temps qu’on commande une nouvelle machine ». Maintenant, monter une nouvelle VM (machine virtuelle), c’est 3 clicks de souris, donc vous faites la demande la veille pour le lendemain et vous comprendrez difficilement qu’on ne vous accorde pas satisfaction très rapidement. Le Time to market touche de plus en plus les salles de production.
• Auparavant, si votre serveur rencontrait un problème de performance, c’était votre serveur, votre responsabilité, vous deviez investiguer et résoudre vous-mêmes ce problème. Maintenant, c’est la faute de la machine virtuelle.

Or, comme nous venons de le voir, les équipes de production sont mal équipées pour faire face à la complexité induite par l’hétérogénéité. D’où vient le problème : d’une saturation CPU ou de la mémoire ou du disque dur ? Pour la mesurer, on devra réunir l’ingénieur système spécialiste de tel type de machine virtuelle, de celui spécialiste de tel OS sur tel hardware. Et le problème peut provenir d’une autre application sur une autre VM sur le même serveur. Il faut développer et maintenir des scripts pour récupérer les bonnes métriques, généralement peu comparables entre les différents systèmes et passer du temps en collecte et analyse de ces données. Le suivi d’alertes et la gestion des incidents sont devenus une préoccupation majeure au sein des salles informatiques.

Donc la virtualisation permet de gagner en optimisation de l’infrastructure mais se traduit par :

• Une inflation des machines virtuelles et des baies de stockage donc en définitive un accroissement du parc informatique.
• Des charges d’exploitation toujours plus élevées.

Il n’y a pas que les projets de développement qui se mesurent en jour/homme ? Le nombre de VMs également. Vous allez me dire : « Et la qualité des développements dans tout cela ?».

C’est très simple. Lorsque les gains en réduction de coûts d’infrastructure sont rattrapés par l’augmentation des dépenses en toujours plus de hardware pour supporter les demandes utilisateurs et en charges croissantes de maintenance et de résolution d’incidents, la réponse des directions informatiques devient ‘Stop’. Quelques propos recueillis lors de cette journée :

• L’équipe de projet qui demande un nouveau serveur de base de données et qui ne l’utilise pas : Stop.
• L’équipe de QA qui veut une base de tests á l’identique de la production, donc encore 800 Go de disque dur supplémentaire : Stop. Réapprenez à programmer des jeux d’essai.
• Les répertoires entiers de données abandonnées dans un coin et qu’on ne sait pas relire, les fichiers Excel dont on ne sait plus à quoi ils correspondent, les utilisateurs qui ne savent pas quelle est la durée réglementaire de conservation des données, toutes les applications que l’on conserve parce que l’on ne sait pas recycler les données : Stop.

Et je garde le meilleur pour la fin. J’ai posé une question stupide : « Existe-il des technologies plus gourmandes en capacité que d’autres ? ». Je pensais que les bases de données, le data-mining et les infocentres étaient plus consommatrices que d’autres. Regards d’incompréhension.

Puis la réponse a fusée : « il n’existe pas de mauvaise technologie, il n’existe que du code mauvais ».

• L’application J2EE dont les fuites mémoire saturent la VM et ses voisines sur le serveur : Stop.
• La requête SQL qui affole les têtes de lecture sur la baie : Stop.
• Les traitements coûteux en boucle : Stop.

Les outils existent qui permettent de visualiser toute la chaîne de bout en bout, depuis le hardware jusqu’à l’application, et d’identifier les process techniques qui saturent les machines virtuelles. Les équipes de production commencent á les mapper sur les applications. Et les ingénieurs système commencent à regarder les outils de qualité de code.

Il n’existe pas de technologie gourmande, seulement du code mal écrit. Mangez votre pain blanc tant qu’il est encore temps.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.