[Episode 04] Réflexion sur le VDI

Même si le sujet est d’actualité depuis un moment, je ne sais pas si tous nos lecteurs sont familiers avec l’acronyme VDI : Virtual Desktop Infrastructure. En quelques mots, cette solution consiste à centraliser les postes de travail pour n’avoir qu’en local un équipement léger. Le principe est de disposer d’une machine virtuelle (sa machine) sur un serveur et de l’utiliser au travers d’un client apportant plus de services que le Citrix/TSE (vidéo, son, …).

Pour avoir évoqué le sujet en interne à plusieurs reprises, avec d’autres DSI et des fournisseurs de solutions, la rentabilité de ce type de solution est très difficile à trouver. Là où il y avait une machine locale, il faut pour ces solutions : un client léger (un vieux PC pouvant aussi faire l’affaire), des ressources sur un serveur, une licence pour la machine sur le serveur. Avec ce nouvel environnement, il faut trouver la rentabilité quand d’un côté on a un PC (sans OS) à environ 600 euros et de l’autre un client léger et la licence VDI à 500 euros (sans compter les ressources du serveur).

Les gains mis en avant par les fournisseurs/prescripteurs sont souvent les suivants :
– Moins d’administration : le client léger est administrable à distance comme la machine virtuelle.
– Moins de maintenance sur le parc : C’est oublié la forte fiabilité des machines d’aujourd’hui.
– Plus de rapidité pour mettre à disposition un environnement : Certainement une des valeurs ajoutées les plus importantes.
Sur cette seule base, les critères ne me paraissent pas suffisants. Le retour sur investissement reste très douteux surtout dans notre contexte de société offshore où la différence de masse salariale ne joue pas ici dans le bon sens (on ne peut pas toujours gagner) 🙂

De notre côté, nous avons identifié les gains majeurs suivants :
– Disposer d’environnements propres : Nos environnements de développement doivent rester « propres » pour limiter les perturbations sur les environnements d’exécution et avoir une gestion de configuration optimale. En disposant de modèles, il est facile de toujours utiliser un environnement issue de la souche. De plus pour l’arrivée d’une ressource (même temporaire), le gain est important.
– Automatisation : Le réel gain se mesure sur l’automatisation et l’intégration de la solution dans notre fonctionnement. Si une personne habile fait la demande et que l’environnement est livré immédiatement sans intervention, là il y a de la valeur sur la réactivité. La bonne partie de la rentabilité se joue donc sur la difficulté d’automatiser la solution et l’intégrer au système d’information.
– Augmentation du niveau de sécurité : Certaines personnes ont une utilisation réduite de la fonction « portable » de leur machine si ce n’est que de travailler depuis chez eux. Pour limiter de se promener avec des données sensibles, moment le plus sensible, il est alors possible d’utiliser la machine distante en ouvrant une connexion VPN avec leurs tokens. De plus, ces environnements centralisés sont plus sécurisés car le stockage bénéficie des redondances mises en place (RAID, snapshot, …).
– Position de travail anonyme : Nous n’en sommes pas arrivés là car nous avons une majorité de sédentaires, mais le fait de pouvoir utiliser n’importe quel terminal (lourd ou léger), y retrouver tout son environnement et quelque soit l’agence, permet de disposer d’un gain important sur le « confort » d’utilisation.
– Achats : Actuellement le catalogue de l’infrastructure doit être mis à jour régulièrement car nos achats sont faits au fil des besoins. Dans cette configuration, les achats se portent uniquement sur des terminaux légers et sur des ressources serveurs.
– Meilleure exploitation des ressources : En concentrant les environnements d’exécution, on augmente évidemment les risques, mais on améliore le taux d’utilisation des ressources. Avec notre projet de cloud privé/hybride/public, ce type de projet nous permet de mieux rentabiliser les investissements que nous faisons. Temporairement, une machine de travail pourrait se retrouver dans le cloud local d’une autre agence si la puissance venait à manquer (temporairement).
– Moins d’administration : Ce n’est pas sur ce poste que nous allons gagner le plus, évidemment. Mais on peut évaluer le gain à une demi année.homme. Le changement d’un client léger ne nécessite pas de connaissance particulière (recâblage à l’identique). L’upgrade de la mémoire se fait de n’importe où dans la console d’administration des ressources. La mise à jour de l’environnement (souche) se déploie automatiquement au démarrage suivant.
– Economie d’énergie : Dans une moindre mesure, il y a aussi des économies d’énergie. Le fait de mutualiser tous les systèmes consommateurs (disques, processeurs puissants, …) et de gérer en parallèle l’optimisation de la configuration (extinction des machines inutilisées).

Et les nomades ? Même si des solutions commencent à arriver sur le marché, nous ne prévoyons pas d’intégrer les nomades à cette démarche pour le moment. Les gains seront très très faibles pour les difficultés à franchir.

Quelques chiffres :
Sur le gain en maintenance et en mise en place, on estime le gain à plus d’une demi-année homme au niveau de l’équipe infrastructure. En faisant un rapide calcul sur les consommations d’énergie, c’est environ 5% de réduction de consommation que nous obtiendrons par cette mutualisation. ll n’y a pas de solution miraculeuse qui ferait baisser spectaculairement les coûts de possession.

Pour la mise en place d’une telle solution ne se fait pas en big bang et les pré-requis ne sont pas à négliger :
– Les ressources centralisées doivent en place et les réseaux doivent être dimensionnés pour ces services.
– La conduite du changement n’est pas négligeable car le public concerné par les gains attendus est celui des développeurs. La séparation physique avec la « sacro-sainte » machine doit s’expliquer, se démontrer, se préparer pour la rendre très transparente.
– Les services réseau doivent être renforcés (routage, VLan, …) pour gérer ces nouveaux trafics.
Le service infrastructure a donc à monter des projets pilotes en collaboration avec la direction technique pour la mise en place de projets pilotes et déterminer plus finement les gains. Cela ne peut pas se faire sans le client.

De mon point de vue, cette démarche est inéluctable à plusieurs égards. Nos environnements (ceux des développeurs) changeant nous incitent à cette centralisation de l’infrastructure pour assurer de la réactivité, une qualité de services et une meilleure utilisation de notre cloud. Dans la partie Cloud, cette approche est également intéressante pour mettre en oeuvre des environnements complets (de développement) à disposition d’utilisateurs en dehors de notre infrastructure. Les environnements « figés » profiteront de ces évolutions pour assurer une homogénéité d’ensemble, mais on est déjà dans une autre étape.

Nous suivons ces solutions depuis deux ans, le démarrage de projets concrets est délicat car les gains sont réels mais limités. Nous devons nous préparer à industrialiser la gestion de ces postes de travail pour répondre aux exigences de notre projet de cloud de services. Mais l’autre élément déclencheur serait une réduction significative du ticket d’entrée pour ce type de solution.

[Episode 03] Un an après l’évolution de notre infrastructure réseau

[Episode 05] Une feature team pour la réalisation des sites web