La société de virtualisation des serveurs, sur le marché depuis 1998, a évolué au fil des années, et se distingue aujourd’hui du cloud, qui offre des garanties moindres. Ghaleb Zekri, architecte sécurité chez VMware, a accordé une interview à Clubic pour en parler.
Ils sont bien gentils chez vmware, mais la virtualisation ne règle pas le problème de fond. Les utilisateurs sont des gros gougnafiers qui ne savent gérer leur parc informatique correctement.
Avec du vmware partout, on a l’impression que c’est plus propre, mais c’est faux et cela ne coupe pas les pattes à la fuite en avant des clients. Pour faire un parallèle automobile, ce genre de client (pour pas dire quasi tous) sont ce genre de conducteurs qui ne savent plus conduire dès lors qu’on leur change la couleur du volant.
Pas compris, c’est quoi le « problème de fond » et la « fuite en avant » dont tu parles?
Ne vois aucune animosité. Ça m’intéresse de comprendre.
C’est pour ca qu’il existe des sysadmin et des netadmin … C’est nous les pilotes de ces outils, l’utilisateur lui, a juste a se mettre aux places arrières et a profiter.
Les révolutions Carbone du numérique n’existent pas, il ne faut pas vendre du rêve avec ce titre. Prenez la courbe d’évolution du Carbone et cherchez « la révolution numérique » numérique dedans et une moindre baisse, il n’y en a pas. On virtualise plus donc il y a aura plus de serveurs virtuels qu’il y en aurait eu de physiques, on ne fait qu’augmenter en sortie donc il n’y aura rien sur le Carbone. Ça a toujours été comme ça et ça le restera. Faire plus avec moins, ça reste faire plus.
Clairement. On rationalise effectivement au niveau des infrastructures, on consomme donc de façon plus rationnelle (les machines qui consomment peu coûtent donc moins, à tous points de vue), et la densité fait tout de même que l’on est plus efficient au niveau énergétique et refroidissement (AMHA).
Dit le mec qui sort de formation vSAN
toi tu as rien compris je pense …
Pas de soucis, je vais tenter de clarifier tout ça.
Le problème de fond est que les clients (grosses entreprises) ont plein de logiciels pour exécuter leur processus métier. Afin d’avoir une ligne de production fiable, ils ont leur logiciels présents en plusieurs exemplaires (instances) : production, préproduction, homologation, recette, intégration, formation, développement … etc. Suivant l’architecture de ces logiciels, cela peut aller d’un serveur à plusieurs dizaines de serveurs par instance de l’application. Là, on a une photo instantanée de ce que le client utilise.
Maintenant, on introduit la notion de temps qui amène avec elle les évolutions fonctionnelles, l’obsolescence matérielle et logicielle … et les opérations de migration adhoc. Tout ça est piloté par des responsables très souvent fonctionnels ayant une culture informatique proche du zéro absolu (cliché de l’utilisateur windows de base).
Résultat des courses, les vieux environnements sont conservés au delà du raisonnable. Au lieu de libérer des ressources, ils les gardent et obligent, de par ce comportement piloté par les angoisses, les services informatiques à acquérir des plateformes vmware supplémentaires au lieu de les renouveler. Ici, on touche du doigt le « problème de fond » c’est à dire que les migrations ne sont jamais emmenées jusqu’au bout. Les responsables de projet mettent en place les évolutions et s’arrêtent là. Ils ne font pas le « ménage » sous prétexte que « ça pourrait servir un jour » ou que « ce n’est pas leur problème ».
Après plusieurs itérations de ce type, je te laisse imaginer la cour des miracles que devient le parc de serveurs global de l’entreprise. Ce que j’appelle la « fuite en avant » est la collectionnite morbide pilotée par des incompétents notoires.
Avant VMWare, on avait plein de serveurs physiques dans les salles machines. L’ajout / suppression / renouvellement de serveurs prenaient plus de temps qu’avec des VM. Du coup, les projets étaient obligés à être plus propre dans leur approche de migration … et le décommissionnement était un passage obligé parce que les « restes de migration » étaient moins discrets qu’avec des VM.
Il faut quand même garder à l’esprit que VMWare a été utilisé à la base à cause des piètres capacités des Windows à pouvoir multi-instancier des applications et/ou à gérer proprement le partage de ressources système entre plusieurs applications (au final, on avait un serveur Windows par instance d’application).
En théorie, tu as raison.
En pratique, on te colle un impératif business et c’est à toi de t’aligner sur les « caprices » de « ménagère de moins de 50 ans ».
Ben, tu penses mal …
C’est toujours le cas, on a toujours 1 serveur virtuel = 1 appli dans 90% des cas
Belle analyse. Pour le décommissionnement, tu as raison. Certains managers sont frileux, et ne prennent pas le risque bien que, dans la plupart des cas, il suffit de faire un p2v et de stocker l’image de la VM sur un stockage bon marché. Mais je peux comprendre la frilosité. Certaines applis historiques ne sont pas ou peu documentées et le reverse engineering pas forcément possible ou trop coûteux donc difficilement « migrables ». Après, il y a les éditeurs (d’applications) qui ne « supportent » que telle ou telle version d’OS, de BD, voire d’hyperviseur, « Ça fonctionne mais ce n’est pas supporté », donc on multiplie les instances, ne trouvant pas de dénominateur commun. Et on a un parc hétéroclite, qui coûte cher à gérer, à patcher…
Autre point : les « Migrations ». Parfois des projets qui peuvent durer plusieurs années. Souvent imposées par les éditeurs, non pas pour des raisons fonctionnelles (il y a toujours un petit + par ci, par là, pour « vendre » le produit) mais pour des raisons financières. Business is money. De plus les « évolutions » (parfois rétrogradations) fonctionnelles ne sont pas, la plupart du temps, demandées par les clients mais imposées par l’éditeur.
L’application X ne sera plus compatible avec l’OS Y mais Z minimum, qui nécessitera des licences (serveurs, peut-être aussi clients), une augmentation des besoins physiques (même virtualisés), de stockage, de redondance, SPF…
Vastes sujets
Effectivement, ces sujets sont bien vastes.
Au fond, l’élément commun à toutes les histoires de migration partielles et de décomissionnement inexistants est le manque de maîtrise de l’outil informatique. Non pas que les gars derrière les claviers soient des billes (et c’est souvent le contraire) mais que les demandes formulées sont faites par des personnes ayant une culture informatique proche de pas beaucoup.
Ce n’est pas tant qu’ils n’ont pas les capacités de faire les choses proprement, mais ils ont des directives de pilotage de projet orientés rentabilité … et « passer le balai » pour faire propre, à leur yeux, ça coûte à court terme. Le long terme, une fois les choses bien gangrénées, coûte encore plus cher à nettoyer, mais bon, ils ne seront plus là pour y faire. C’est un « cadeau » qu’ils laissent sous le tapis pour le suivant.
VMWare aura beau expliquer en long, en large et en travers que les VM c’est bien pour tout le monde y compris la planète, le vrai problème à traiter est le manque de professionnalisme chronique dans la gestion des environnements applicatifs.
Pour ma part, afin de mieux exploiter les capacités de traitements des serveurs physiques actuels (ce que j’appelle le rendement applicatif), je suis partisan d’alléger les couches logicielles en transformant les plateformes ESX en serveur Docker / Kubernetes.