Bernard Ourghanlian, Directeur Technique et Sécurité de Microsoft France (3)
Il faut complètement repenser le déploiement du poste de travail - 3e Partie
HL : Est-ce la fin des applications installées au sens traditionnel du terme ?
BO : Oui et il est probable que l'on verra sous peu des applications Microsoft livrées également sous la forme de containers App-V. Une des hypothèses sur lesquelles on travaille consiste à étendre ce modèle de déploiement au Web. Imaginons que toutes les applications de Microsoft soit disponibles sur un portail Live en mode abonnement ou en mode de paiement à la consommation.
A partir du moment où on est dans ce mode là, je double clique sur mon application, je la streame sur mon poste de travail et l'application est là.
La virtualisation applicative est extrêmement importante, pas seulement dans l'environnement de l'entreprise, mais aussi pour les particuliers ayant besoin d'une application temporairement.
Prenons Excel avant la déclaration d'impôt. C'est typique d'un usage temporaire. Dans ce cadre, la virtualisation applicative est adaptée car il n'y pas besoin d'installer quoi que ce soit sur le poste de travail. J'installe l'application dans un container et quand je n'en ai plus besoin, il suffit que je supprime le container et je n'ai plus d'application... C'est autre chose que le mode dans lequel on a l'application, on l'installe, puis on la désinstalle...
HL : Et le scénario ou un utilisateur a besoin de travailler depuis plusieurs machines ?
BO : Un des scénarios intéressant dans ce contexte là, c'est par exemple ce qui arrive avec les fonctionnalités de BranchCache (1). L'intérêt est que l'on utilise un cache distribué où le même élément est en mémoire cache, géré en mode peer to peer : il est directement disponible sur l'ensemble des postes de travail d'une agence, pour en faire en sorte qu'on puisse avoir un cache qui soit répliqué et qu'en même temps, on ait la possibilité de faire en sorte que le transfert réseau ne se fasse qu'une fois.
Cela évite d'avoir un serveur en agence et ça permet dans un scénario où on peut avoir l'environnement applicatif App-V qui ne soit téléchargé qu'une fois, de faire en sorte que la mise à jour ne se fasse qu'une fois et qu'ensuite, elle soit disponible sur l'ensemble des postes de travail.
HL : Et pour un scénario grand public ?
BO : Dans le cas d'un scénario de ce type, c'est un peu plus compliqué, sauf à imaginer que l'on ait Home Server à la maison. Ou encore d'utiliser Live Mesh pour synchroniser tous ces éléments...
HL : Cela ne répond pas à toutes les problématiques. Quid si je suis en déplacement dans un cybercafé, et j'aimerais retrouver mon environnement applicatif
BO : Dans ce cas, le scénario à envisager c'est probablement un scénario de type mémoire flash, clé USB sécurisé stockant cet environnement virtualisé.
Sur le plan licence, ce n'est pas simple. C'est un scénario qui, sur le plan technique, a déjà été réalisé. On sait mettre une image virtuelle d'une application telle qu'Office sur une clé USB virtualisée. Cela n'existe qu'à l'état de prototype parce que, sur le plan du contrôle de licences, c'est compliqué à mettre en place. Cependant, on y travaille.
H : Partons d'une situation où on utilise App-V, MED-V pour aller progressivement vers Windows 8 et Hyper-V V3. Entre ces deux phases, que va-t-il se passer ?
BO : Pour moi la chose qui va arriver, c'est une évolution de Virtual PC pour supporter Windows 7 et permettre le mode de fonctionnement où l'on va avoir la notion de bac à sable sécurisé dans une machine virtuelle. On va pouvoir déclarer une machine virtuelle pour les applications d'entreprise, une autre pour surfer sur Internet sur laquelle il peut arriver des problèmes... D'une manière générale, Virtual PC embarquera, sur les versions Entreprise de Windows 7, une partie de MED-V.
H : Donc ça c'est MED-V ?
BO : Oui. En fait, c'est une fonctionnalité qui va reposer sur un couplage d'une partie de MED-V (il faudra toujours utiliser MED-V si l'on veut gérer en central ses machines virtuelles) et de Virtual PC.
Au niveau de Virtual PC, Il fonction de décoration des fenêtres qui montre le niveau de dangerosité et ce à quoi l'utilisateur est autorisé. D'une manière générale, les fenêtres d'une machine virtuelle Windows XP qui sera exécutée dans ce mode sous Windows 7 seront décorées comme les anciennes fenêtres Windows XP et pas comme les fenêtres natives Windows 7 afin que l'utilisateur puisse bien faire la différence, même si son expérience d'utilisation sera complètement transparente.
HL : Dispose-t-on de données de coûts qui soient liées à la distribution, à l'installation des applications sur les postes de travail, au fait de les patcher versus les scénarios que vous décrivez ?
BO : Je ne crois pas. On a des données sur l'optimisation d'infrastructure où, en fait, on a une évolution du coût en termes de TCO qui est fonction du niveau de maturité de l'infrastructure de l'entreprise. Ces données ont été élaborées en partenariat avec le Gartner et IDC. En ce qui concerne la problématique que vous mentionnez, c'est un sujet sur lequel on travaille.
HL : Ce sera sans doute un argument clé qui permettra de convaincre les DSI
BO : Oui mais quand on explique à une DSI qu'en utilisant simplement la virtualisation applicative, rien d'autre, il est capable de streamer ses applications, de les distribuer depuis un serveur central, on est écouté.
HL : Oui, mais cette capacité est subordonnée à la souscription de la Software Assurance !
BO : Je suis d'accord.
HL : Même si Microsoft présente MDOP comme étant un produit qui a connu un succès très rapide, quand on compare le nombre de licences MDOP par rapport au parc corporate, on reste sur des chiffres très faibles.
BO : C'est vrai en France et nettement moins ailleurs. Un des sujets où la France est particulièrement en retard, c'est sur la Software Assurance (SA). Il y a beaucoup de pays, en Allemagne, en Angleterre, aux Etats-Unis où la situation n'est la même. C'est un sujet pour lequel on reçoit beaucoup de critiques. On doit progresser.
HL : Cela va-t-il va évoluer avec Windows 7 ?
BO : Vous voulez dire en termes de licence ? Je ne pense pas. Si c'était partout difficile de vendre la SA, il pourrait y avoir des volontés. Mais comme c'est un problème plutôt français...
HL : En ce qui concerne les éditions de Windows 7, certaines fonctionnalités supposent de disposer de Vista Enterprise et donc de la SA, ces fonctionnalités seront-elles également exclusives de Windows 7 et incluses dans la SA ?
BO : Je ne sais pas. Il faudra en discuter avec des responsables licences Windows. Ce n'est pas un sujet simple.
On n'est pas très loin d'un changement de business model quand on pense à la notion de consommation du logiciel à la demande. Dans le grand public, il est évident que cela sera probablement la première chose qui sera demandée. Il faut donc faire la transition depuis un business model fondé sur des licences à usage potentiellement perpétuel vers un modèle dans lequel on fonctionne plutôt par abonnement.
On bien encore « achat one shot pour une durée limitée », ce qui est encore un business model totalement différent. Cette transition de business model est complexe surtout quand il y a derrière des dizaines de milliards de dollars à la clé.
En même temps c'est intéressant parce que cela réduit le taux de piratage en autorisant l'essai de logiciel. En fait, il y a beaucoup d'éléments positifs aussi mais il faut trouver la bonne façon de faire cette transition.
HL : Il y a un scénario dont on n'a pas parlé, celui du VDI (Virtual Desktop Infrastructure) également proposé par Citrix qui consiste à héberger des images systèmes de poste de travail sur des serveurs. Je pense à XenDesktop. Quel rôle voyez-vous jouer à cette architecture ?
BO : Cela peut satisfaire certains scénarios d'usage mais c'est une solution très chère parce que le nombre d'images virtuelles qui peuvent être supportées avec des performances raisonnables sur un seul serveur est limité. On va publier un livre blanc sur ce sujet qui va permettre de déterminer le nombre de machines virtuelles Vista ou Windows XP que l'on peut utiliser sur des serveurs avec, par exemple 16 processeurs, et beaucoup de mémoire. On se rend compte que le nombre de machines virtuelles est limité.
Ainsi, même en utilisant Citrix Xen Desktop pour réaliser le brokering de connexion, il faut un octoprocesseur avec 32 Go de mémoire avec 4 interfaces réseau pour supporter : 45 machines virtuelles XP (512 Mo) ou 28 machines virtuelles Vista (1 Go) ; quand on a des dizaines et des dizaines de postes de travail à virtualiser, c'est très coûteux.
La raison en est que la capacité de vrai partage de mémoire dans un cadre de machines virtuelles est relativement limité et qu'utiliser une machine virtuelle n'est pas « gratuit » ; il faut aujourd'hui consommer pas mal de CPU pour les faire fonctionner ; idem pour la mémoire et elles ne sont en général pas très performantes en termes d'entrées / sorties.
Ce sont des scénarios qui sont relativement coûteux au sens où des dizaines de milliers de postes à virtualiser nécessiteraient des milliers de serveurs. Et le gain que l'on a pour passer d'un nombre de dizaines de milliers de postes de travail à plusieurs milliers de serveurs ne supprime pas la problématique de déploiement. Par ailleurs, la virtualisation et donc l'affichage à distance présente un certain nombre de contraintes. Par exemple, le support d'un affichage graphique de bonne qualité. Je pense à l'utilisation du mode Aero en mode Terminal Services inclus Windows Server 2008 R2.
HL : Faisant suite au rachat de Kidaro l'année dernière...
BO : Exactement... On va avoir une interface graphique sur le serveur dont on va se servir des moyens de calcul pour ne transférer que la bitmap.
HL : Est-ce plus efficace que de transférer uniquement les données permettant de redessiner les éléments d'interface sur le poste de travail ?
BO : Quand on commence à avoir des choses complexes comme des ombrages, de la transparence, c'est impossible, il faudrait rafraîchir en permanence. C'est la raison pour laquelle il y a cette volonté de pouvoir supporter soit du matériel partagé sur le serveur, soit d'utiliser intelligemment les ressources matérielles présentes sur le poste de travail.
Ce sont des choses qui seront disponibles avec Windows Server 2008 R2. Une autre limitation familière à tous les utilisateurs de Terminal Services, c'est la problématique de la redirection des entrées sorties, par exemple des ports USB : si je veux être capable sur une application en central de pouvoir utiliser, qui mon imprimante, qui mon scanner, qui ma clé USB, j'ai de nombreux problèmes.
En effet, le déport de ports marche plus ou moins bien et nécessite à chaque fois de tester sérieusement. Ce n'est pas parce que j'ai une application « posée » sur un serveur et que je la virtualise que, pour autant, elle marche instantanément en redirection d'affichage. Ces problèmes sont connus et la plupart de nos clients les ont déjà expérimenté.
Dans un usage typiquement de type « call center » où les applications sont toujours les mêmes, les scénarios restent identiques et dans un contexte où le taux de disponibilité est clé, c'est un scénario où l'utilisation d'un environnement VDI fait sens. On a alors un usage du poste de travail de type « task worker » basé sur des tâches répétitives, sur l'utilisation de modèles de réponses prêtes à l'emploi ... Dans cet environnement il faut être capable de changer rapidement une machine virtuelle par une autre afin de ne pas rester bloqué par une machine sur laquelle on a un virus. Dans un tel contexte, VDI est tout à fait envisageable.
Par contre, dans un contexte plus banal d'information worker de réalisation de tâches sophistiquées, nos clients nous interrogent sur les applications VoIP ou communications unifiées dans un modèle où tout est en central » ?
De même, si je suis un utilisateur important du graphique, si j'ai de gros besoins en termes de collaboration, de présence ... ce sont des scénarios où l'utilisation de ce type d'architecture n'est pas adaptée.
Il faut également considérer que, dans l'immense majorité des entreprises, il y a une migration naturelle des postes de travail fixes vers des postes de travail portables. En mode distant, une connexion vers le data center en mode VDI risque de ne pas me mener très loin car je n'aurai pas toujours accès au réseau.
HL : Qu'en est-il du mode SaaS qui représente une alternative intéressante en réponse aux problématiques de déploiement applicatif ?
BO : C'est une des raisons pour laquelle il y a aussi des évolutions de Microsoft dans ce domaine.
A horizon de cinq ans, dans un contexte Windows Azure, etc., la perspective générale consiste dans sorte de banalisation du fait que j'ai des applications qui sont natives, hébergées dans une machine virtuelle ou hébergées dans le « nuage ».
Si j'essaye de me projeter dans une vision Software + Services, j'ai des applications qui sont en local, d'autres qui sont dans le nuage, j'ai des données en local et des données dans le nuage et je ne fais pas la différence. Cependant, si on veut que cela soit réalisé d'une manière acceptable pour l'utilisateur, il faut à la fois résoudre un certain nombre de problèmes loin d'être simples par rapport à des problématiques de type : où sont les données, sont elles confidentielles, est ce que j'ai envie de les mettre chez Microsoft, Google... ou est-ce que je considère que c'est un peu risqué et qu'il vaut mieux que je les aie chez moi ?
Ne faudrait-il pas, si j'ai une application que j'utilise très souvent, que cette application vienne automatiquement sur ma machine, plutôt qu'être exécutée en permanence avec un temps de latence qui est celui que l'on connaît sur Internet ? Idem pour les données : Ne faudrait-il pas faire en sorte qu'en fonction du profil d'utilisation des données et des applications, automatiquement ces dernières soient répliquées automatiquement vers mon poste de travail où j'aurai le meilleur temps de latence ?
Ce temps de latence est un vrai sujet. Si j'ai mes données qui sont hébergées dans un Datacenter qui est à 12 000 km de chez moi, cela ne pose pas de problème si j'ai un petit volume de données, mais si je commence à avoir des « vraies » données, genre base de données, ou même un gros tableau Excel ou un gros fichier PowerPoint, je vais attendre un certain temps.
C'est encore l'une des raisons qui militent en direction de Software + Services plutôt que Software as a Service. Si j'ai, comme cela s'est passé il n'y a pas très longtemps chez Salesforce.com ou chez Google, un gros problème, j'aimerai bien pouvoir continuer de travailler. Ce qui leur est arrivé peut arriver à n'importe qui : on a vu ce qui s'est passé récemment avec la tempête.
Si un data center s'était trouvé dans la région des landes, à mon avis il avait quelques soucis à se faire, ne serait ce que parce que il n'avait plus de courant ! La continuité de fonctionnement suppose une infrastructure dont tous les composants sont opérationnels : je peux avoir chez moi un PC qui tourne sur sa batterie, idem pour mon mobile mais si le DSLAM de mon fournisseur d'accès est indisponible...
HL : Vous parliez d'un environnement dans lequel tout est parfaitement intégré, dans lequel on ne fait pas de différence entre applications locales et applications distantes, ditto pour les données, etc. ... comment comptez vous vous y prendre pour parvenir à ce résultat ?
BO : C'est un peu tôt pour en parler mais on y travaille. Il faut non seulement assurer une transparence de l'accès aux données mais aussi faire en sorte que les données soient répliquées de façon intelligente pour être là où il est le plus raisonnable qu'elles soient. Typiquement si j'ai une application locale qui accède à des données distantes, peut être serait-il intelligent de rapatrier les données en local si je peux.
De même que si j'ai un usage vraiment épisodique de certaines applications, pourquoi ne pas les déporter à distance dans le nuage ... C'est le genre de sujet sur lequel il y a encore beaucoup à faire. A terme l'objectif est de faire en sorte que Live Mesh soit présent dans toutes les applications vendues par Microsoft sans exception.
C'est-à-dire qu'il sera nécessaire qu'il y ait la fonction de réplication, la fonction « peer to peer » que l'on trouve dans Live Mesh en standard. Notre direction est de faire en sorte qu'à travers Live Mesh qui sera intégré partout, pour tous les utilisateurs, l'accès aux données et aux applications soit extrêmement banal et qu'il ne soit plus nécessaire de se poser la question de leur emplacement.
HL : On est encore très loin de cette vision ...
BO : Il y a encore beaucoup de choses à faire dans Live Mesh pour que cela soit possible et il faut rendre toutes les applications Live Mesh aware, mais cela représente notre direction stratégique et nous venons juste de nous réorganiser pour intégrer Live Mesh dans l'équipe Windows sous la responsabilité chez Steven Sinofsky.
La raison de cette réorganisation est de permettre cette évolution. L'objectif est de faire en sorte que le nuage soit vu comme une extension naturelle du bureau et que l'utilisateur ne fasse pas la différence.
HL : N'est pas ce qui se passe dans le cas de MOS (Microsoft Online Services) où les données de messagerie ou de collaboration sont hébergées ?
BO : Le cadre est un petit peu différent : il y a une homogénéité parce que, dans la pratique, toute la partie données, stockage, application se trouve chez Microsoft au lieu d'être dans mon data center.
Ça ne change pas vraiment l'architecture du système tel qu'elle est aujourd'hui mis en œuvre. Par contre, avec Azure et notre approche « S + S », on vise un changement total de l'architecture. C'est une révolution complète en termes de façon d'appréhender les choses.
Il s'agit d'une inflexion stratégique qui émane de Ray Ozzie et qui n'existait pas du temps de Bill Gates qui était probablement plus consensuel. Ozzie est dans un mode où il laisse toute latitude aux groupes produits mais leur explique que la stratégie technique de Microsoft n'est pas discutable : « vous avez un produit qui est Live Mesh Aware ou vos produits n'existent plus »...
HL : A partir de quand s'appliquera cette politique ?
BO : Maintenant...
HL : Elle s'appliquera donc à Office 14 !
BO : C'est sans doute un peu tôt pour Office 14 car on est déjà très avancé dans la conception mais on peut imaginer qu'il y ait des évolutions d'Office Live Workspace allant dans cette direction.
HL : Je voudrai terminer sur le partenariat entre Microsoft et Citrix
BO : Comme beaucoup d'autres, c'est un partenariat dit de « coopétition ». Il y a bien longtemps que l'on est partenaires avec Citrix mais aussi concurrent. Cette situation est courante dans le monde de l'informatique.
HL : L'annonce de l'hyperviseur poste client de Citrix va venir en concurrence avec les évolutions d'Hyper-V ?
BO : Ce n'est pas impossible, reste à voir ce qu'il y aura dans l'hyperviseur en question. Nous considérons l'hyperviseur comme une fonction de base du système. Ensuite, la question sera de savoir s'il y aura de la place pour un grand nombre d'hyperviseurs sur le marché.
HL : Quelle est la réaction de vos clients quand vous leur présentez le panorama des solutions de virtualisation dont nous venons de parler ?
BO : D'une manière générale, je pense que toutes les entreprises voient dans les problématiques de déploiement, de gestion du poste de travail, une vraie calamité. Et on a une vraie responsabilité sur cette question.
Pourquoi les gens ont-ils envie d'aller vers des clients Web ce qui, à bien des égards, constitue un contre-sens total ? Si l'on regarde aujourd'hui le niveau de productivité de développement des applications Web (même si la donne change un avec Silverlight), et quand on voit des Google Gears, cela représente un non-sens absolu. Pas parce que le concept de persistance locale en mode déconnecté est mauvais mais parce que la productivité en Javascript est déplorable.
HL : Cela dépend du navigateur que vous utilisez ...
BO : Cela ne dépend pas du navigateur, ce n'est pas un problème de performances. Je parle uniquement de la vitesse de développement de n'importe quel développeur qui travaille en Javascript. On ne va quand même pas revenir à des langages de script antédiluviens comme Javascript...
Il faudrait au moins multiplier par dix la productivité des développeurs. Encore une fois, cette évolution est un non sens. Si l'on y réfléchit bien, le logiciel reste aujourd'hui un artisanat qu'il est absolument nécessaire de faire passer enfin à l'ère industrielle. Il faut penser productivité des développeurs et non revenir à des langages de ce genre.
On dispose de la loi de Moore pour les processeurs ; il est temps que l'on puisse bénéficier d'une loi de Moore pour la productivité des développeurs...
Je ne parle pas des problématiques de temps d'exécution car ce n'est pas cela la question. La vraie question, c'est comment on améliore la productivité des développeurs.
On l'a déjà fait régresser parce que finalement, quand on regarde sur des environnements mono-machines, ce que permettaient de faire, dans les années 90, des L4G ou des ateliers de génie logiciel, on avait une productivité qui était meilleure que celle qu'on a aujourd'hui quand on développe dans un environnement distribué en C# ou en Java. On a perdu en productivité, ce qui est quand même paradoxal même si la complexité des environnements a considérablement augmenté...
Il faut repenser la productivité du développement logiciel et cela ne va certainement pas dans le sens de la massification de l'utilisation des langages de script d'assez bas niveau. Il faut « simplement » que l'informatique et le développement passent de l'artisanat à l'ère industrielle ; en bref, que l'informatique fasse enfin ce que l'industrie lourde a réalisé à la fin du 19ème siècle... Sa révolution...
(1) Dans Windows 7, BranchCache accélère la réactivité réseau des applications. Les utilisateurs distants bénéficient alors d'une expérience aussi riche que sont qui sont installés lovalement. En accédant au contenu stocké sur Windows Server 2008 R2, ils ne subissent plus le décalage dû au téléchargement des fichiers depuis la maison mère. Dès que le département informatique active BranchCache, une copie des données consultées à partir d'un site Web intranet ou d'un serveur de fichiers est mise en cache au niveau local. Lorsqu'un autre utilisateur du réseau demande le fichier, il accède presque immédiatement au contenu qui est dorénavant hébergé dans le cache local. (Source IT Channel)