Virtualisation d'applications: Un effet de mode? 1/5

J'ai décidé de diviser ce billet en 5 parties pour expliquer pourquoi la virtualisation d'applications peut apporter une réponse à certains problèmes inhérents à l'administration des postes de travail.

Depuis quelques temps la virtualisation en informatique est devenue un sujet très à la mode, on virtualise les systèmes d'exploitation (serveurs et clients) ainsi que l'accès et l'administration de systèmes de stockage (SAN, NAS) sans compter les accès aux réseaux !.

Les applications n'échappent pas à la règle. Dans le monde "Windows" l'installation d'une application (d'un logiciel) nécessite la modification du registre et la copie de dizaines, voir de centaines de fichiers sur le disque dur de l'ordinateur. Il s'agit d'une opération courante qui peut se répéter de dizaines de fois pendant la durée de vie du système.

Chaque application installée va donc, pour ses besoins propres de fonctionnement, installer des librairies ou bibliothèques dynamiques (DLL), modifier le registre (paramètres, enregistrement des DLL, etc, etc), créer de raccourcis, ajouter de services, etc, etc.

Mais qui sont donc ces "DLL's" ?

Les DLL sont de librairies dynamiques chargées en mémoire lors de l'exécution de l'application principale. Elles contiennent des fonctions standards ou privées utilisées de façon ponctuelle . La grande majorité des applications Windows utilisent et fonctionnent avec de DLL dites "partagées".

Si lors de l'installation d'une application une autre sans lien apparent cesse de fonctionner alors on est face au problème dit de "l'enfer des DLL" (ou "dll hell"). C'est à dire que les deux applications sont "connectées" via une DLL ou librairie partagée. La dernière application installée à changé la librairie partagée par une version plus récente ce qui a rendu la première inutilisable. Un autre exemple: Deux versions d'un même logiciel installées sur le même poste. Il y a forte chance que l'on rencontre le même type de problème. Alors, comment sortir de ce piège?

La solution "idéale" serait que chaque application fonctionne avec sa bonne version de "DLL partagée " de façon protégée , encapsulée en quelque sorte. Les dernières versions de "Windows" (2000, XP, Vista) se sont attaqué au problème avec plus ou moins de succès (dllcache, WFP, DLL privées, correctifs, redirection de bibliothèque de liens dynamiques, etc, etc) mais cela reste de l'ordre plutôt de "premiers secours" que de véritable soin.

Dans le monde Unix (linux) les librairies partagées ("Shared librairies") sont autrement implémentées et ne posent pas ce type de problème. Aussi, la plus part de développeurs font ce que l'on appelle des "Applications statiques", elles comportent toutes les bibliothèques nécessaires dans le programme compilé.


De plus, les installations, réinstallations et désintallations qui font partie du "cycle de vie" normal d'un poste de travail vont provoquer une dégradation de performances du système dûe à la fragmentation du registre et du disque dur ainsi qu'à certaines "traces" laissées ci et là après chaque désintallation.

Dans la deuxième partie du billet je vous présenterais les différentes solutions que j'ai eu le temps d'étudier avec pour chacune l'incontournable liste de PRO&CONS...