Entretien avec Bernard Ourghanlian sur la virtualisation
La virtualisation est un sujet sur lequel Microsoft est perçu comme essayant combler son retard par rapport à d’autres éditeurs. Windows Server 2008 arrive dans peu de temps et apporte Windows Server Virtualization, récemment baptisé Hyper-V, dans ses bagages. Comment peut-on comparer cette nouvelle offre par rapport à l’offre VMware notamment ?
Bernard Ourghanlian : Je vais répondre à cette question mais je vais auparavant faire un détour. La virtualisation, même s’il ne s’agit pas d’une nouvelle technologie en soi, est probablement l’innovation majeure depuis les quinze dernières années en informatique. La virtualisation est apparue chez IBM avec VM qui doit en être au-delà de sa quarantième année d’existence. Ce qui me paraît aujourd’hui être l’élément le plus important c’est la conjonction de tout un tas de facteurs qui viennent apporter de nouvelles solutions. Ces facteurs comprennent notamment l’évolution du hardware qui fait qu’aujourd’hui la virtualisation devient accessible à tous. On assiste à la démocratisation de la virtualisation que l’on constate aujourd’hui du côté des serveurs, mais la vraie révolution à mon sens se fera au niveau des postes de travail.
En entreprise ou pour le particulier ?
B.O : Partout, pour un certain nombre de raisons sur lesquelles je vais revenir.
Quand on regarde l’évolution du hardware, on fait face un phénomène extrêmement important qui représente probablement le phénomène le plus capital depuis au moins quarante ans, depuis l’énonciation originelle de la loi de Moore. Ainsi, si cette loi n’est pas remise en cause, la perspective de voir la fréquence d’horloge des processeurs augmenter régulièrement n’est plus devant nous. On ne sait plus dissiper la quantité de chaleur créée à la surface des composants. On sait désormais que les prochaines perspectives d’évolution ne reposent plus sur l’augmentation indéfinie des Gigahertz. On restera très probablement dans les prochaines années autour des 3-4 Ghz et on devrait assister à des progrès dans le domaine des économies d’énergies.
On assiste aujourd’hui à l’apparition de processeurs multi-cœurs qui sont en train de se généraliser. On voit des stations de travail avec deux fois des quadri cœurs. Il est difficile aujourd’hui d’acheter un portable qui ne soit pas double cœur. Dans un avenir proche on aura des machines dotées de 32, voire de 64 cœurs de manière banale. Ce qui est intéressant dans ce contexte c’est que dans un premier temps cela représente un challenge absolument gigantesque parce que pour être capable d’utiliser « n » processeurs, il va falloir paralléliser les logiciels de telle façon que l’on puisse exécuter « n » threads en parallèle sur ces « n » cœurs et faire en sorte que le temps total d’exécution soit diminué. Le problème c’est que l’on ne sait pas écrire les logiciels en mode parallèle en dehors de cas particuliers comme certains logiciels scientifiques, par exemple dans les domaines du calcul de structures, ou de la dynamique des fluides. Le fait est qu’aujourd’hui on a très peu de capacité de traitement en parallèle pour des logiciels courants. On peut se poser la question de savoir comment paralléliser un logiciel comme Word. Il y a des voies d’amélioration, mais si on est raisonnable, on n’aura jamais un Word qui sera capable d’utiliser dix, vingt ou trente processeurs sauf à imaginer de changer fondamentalement l’interface entre l’homme et la machine et donc d’utiliser beaucoup plus la puissance de calcul pour être capable d’avoir de nouvelles façons de saisir des informations. Typiquement on peut penser à de la reconnaissance de la parole, à l’écriture manuscrite, à des agents intelligents, etc.
Toujours est-il que pour l’immense majorité des logiciels il y a très peu de logiciels qui sont parallèlisables en utilisant les méthodologies et les langages d’aujourd’hui. Pour ces logiciels, il y a peu de possibilités de bénéficier de cette capacité de calcul qui devient disponible. La raison essentielle tient vraisemblablement à ce que nos processus cognitifs ne sont pas adaptés à la réflexion en parallèle. On a donc du mal à écrire des logiciels parallélisés parce que ce n’est pas un mode de fonctionnement auquel on a l’habitude de faire appel. Il y a également de manière très claire un déficit d’environnements de programmation. On pourrait confier à la machine le soin d’écrire des programmes qu’on aurait préalablement modélisés, ce qui représente un des plus grands défis des prochaines années pour une société comme Microsoft, à savoir l’écriture d’outils de programmation, de langages qui vont permettre de travailler dans des environnements massivement parallèles. Si l’on est réaliste ce sont des problématiques que l’on ne sait pas correctement adresser, ni maintenant ni dans un avenir proche. Il faut donc repenser les outils de développement.
Le système d’exploitation aussi
B.O. : Bien sûr, même si le système d’exploitation est un des composants qui sait le mieux travailler en parallèle. Des progrès sont possibles, par exemple en exprimant mieux le parallélisme. Dans les langages classiques qui sont à notre disposition aujourd’hui, les C#, Java, C++ on ne dispose pas de dispositif intelligent permettant d’exprimer le parallélisme en dehors de la description de sections critiques. Il y a des progrès théoriques et technologiques en cours, comme une gestion transactionnelle de la mémoire (Software Transactional Memory) permettant à « n » threads d’accéder à une zone de données en mémoire tout en garantissant l’intégrité des transactions effectuées sur cette zone de données.
Venons en maintenant à la virtualisation. Avec la généralisation du hardware capable de gérer cette virtualisation et cette incapacité un peu pathétique que l’on a d’utiliser intelligemment tous ces cœurs on a une conjonction intéressante qui consiste à dire : et si on utilisait toute cette puissance de calcul pour faire ce que vraiment cherche à faire la virtualisation ?
On dit un peu tout et n’importe quoi à propos de la virtualisation. On vend la virtualisation en disant que cela va permettre de mieux utiliser les capacités de calcul et que plutôt que d’utiliser des machines à 20 % de leur charge nominale on va pouvoir les utiliser à 80 %. Certes, c’est un usage intéressant : c’est le paradigme de la consolidation de serveurs mais il s’agit d’une vision extraordinairement restrictive de tout ce que permet de faire la virtualisation. L’intérêt majeur de la virtualisation c’est de pouvoir, comme son nom l’indique, virtualiser; c’est-à-dire de pouvoir faire en sorte que, comme on introduit un niveau d’abstraction supplémentaire entre une vision physique des ressources et une vision logique de celles–ci, on puisse imaginer de pouvoir beaucoup plus qu’aujourd’hui isoler les couches logicielles qu’elles soient dans une présence horizontale ou dans une présence verticale sur la même machine.
Ce que cela signifie concrètement, c’est qu’aujourd’hui un des scénarios intéressants de la virtualisation c’est de pouvoir héberger plusieurs versions de la même application sur des machines virtuelles différentes dans une machine physique unique. On pourrait appeler ceci la virtualisation horizontale, plusieurs versions de la même application qui cohabitent sans interférer. C’est l’intérêt de la capacité d’isolation apporté par les machines virtuelles.
Il y a un autre intérêt, tout à fait fondamental également, qui fait que je deviens capable grâce à la virtualisation de faire en sorte que finalement les dépendances par rapport à mon système d’exploitation, les dépendances par rapport à mon middleware en tant que couche intermédiaire deviennent des dépendances qui sont isolées pour moi.
Pour prendre un scénario qui pour le moment est encore de l’ordre de la vision mais qui est un scénario sur lequel Microsoft travaille, on peut imaginer la chose suivante : je suis sur un poste de travail ou un serveur, chaque application est accompagnée d’un manifeste qui est en fait l’équivalent du manifeste que l’on trouve dans l’environnement .NET (aujourd’hui un fichier XML qui va décrire les dépendances ou les présupposés de mon application par rapport au monde qui l’entoure). Imaginons que je suis sur une prochaine version majeure de Windows, Windows 7 ou Windows 8 et que je cherche à activer une application. De deux choses l’une, soit les dépendances que j’ai exprimées dans ce manifeste sont entièrement disponibles dans Windows 7 ou 8 et j’active mon application comme si de rien n’était. Soit ce n’est pas le cas et j’ai donc la nécessité de faire appel à un certain nombre de fonctionnalités anciennes d’un système d’exploitation qui ne sont plus présentes dans Windows 7 ou 8, alors je vais pouvoir dynamiquement et de façon totalement transparente pour l’utilisateur instancier soit une virtualisation applicative (je reviendrai sur cette notion), soit une machine virtuelle telle que l’on la connaît dans un environnement VMware ou Virtual PC pour faire en sorte d’apporter à mon application ce dont elle besoin pour pouvoir fonctionner. Quand je suis dans un environnement tel que celui là je ne suis plus dépendant des versions de système d’exploitation et du middleware associé. Je vais dynamiquement instancier ce dont j’ai besoin pour pouvoir faire fonctionner mon application. Ce qui veut dire en fait que j’utilise la puissance CPU à ma disposition pour utiliser toutes ces machines physiques qui sont présentes sur ces processeurs multi-cœurs pour être capable dynamiquement de créer l’environnement dont mon application a besoin.
Ce qui veut dire que si je suis DSI, responsable d’une ligne applicative métier dans mon entreprise, je ne vais plus avoir besoin de me préoccuper des vicissitudes de l’infrastructure, je vais pouvoir faire évoluer mon application à mon rythme en fonction de ce que j’ai choisi de faire. Si mon application est « en mode maintenance » où plus rien n’évolue, je peux prendre la décision de faire vivre cette application pendant dix ans, sans pour autant solidifier, geler le système d’information qui se trouve en dessous. Je peux donc avoir sur la même machine, qu’elle soit serveur ou qu’elle soit poste de travail plusieurs versions, plusieurs philosophies d’évolution du système d’information qui cohabitent. Je ne suis plus obligé, comme c’est aujourd’hui le cas, si je prends la décision de migrer vers Windows Vista de m’assurer de la compatibilité de toutes mes applications avec le nouveau système. Cela implique aujourd’hui, soit de faire évoluer mes applications, soit de racheter une nouvelle version chez mon fournisseur même si je n’en ai fonctionnellement pas besoin. J’ai transformé une problématique de migration de système d’exploitation vers quelque chose de plus important qui est la question de la gestion du cycle de vie de tout le patrimoine applicatif. L’idée c’est de permettre sur le même environnement de faire cohabiter des versions différentes du système d’information, des vitesses différentes d’évolution du système d’information, de faire en sorte que si je prends la décision de faire évoluer très vite une application et de pouvoir tenir compte des évolutions soit du middleware, soit des OS , je vais pouvoir faire évoluer ces composantes sur la plateforme de base mais je n’aurai pas l’obligation que cela affecte toutes mes applications. Pour moi la vraie promesse de la virtualisation, au-delà de la consolidation de serveurs et au-delà des plans de reprise d’activité, est autour de l’amélioration de l’agilité du système d’information parce que l’on va éliminer les dépendances entre toutes les briques de base constitutives de ce système.
Ce qui est très intéressant et c’est la raison pour laquelle je pense que la vraie révolution de la virtualisation se manifestera surtout au niveau du poste de travail c’est qu’on se rend compte qu’un des gros problèmes de la plupart de nos clients c’est qu’à chaque fois qu’ils ont à migrer ou à changer une version majeure du système d’exploitation, pour prendre le cas de Vista, ils sont confrontés avant tout au problème de la compatibilité applicative. Si on prend l’exemple de quelques uns de nos clients qui ont un patrimoine de quelques 4 000 applications sur le poste de travail, rien qu’une seule journée passée pour tester les éventuelles régressions apportées par le nouvel système d’exploitation, ça représente 4 000 jours hommes, un investissement énorme. Quand un client à 4 000 applications et qu’il veut en faire évoluer deux, il est obligé de faire évoluer les 3 998 autres au même rythme que les deux autres. Il s’agit évidemment d’un cas extrême. Le gros intérêt de la virtualisation c’est de pouvoir s’affranchir des dépendances entre les applications, les couches middleware et le système d’exploitation et donc de permettre finalement au système d’information d’évoluer à son rythme à chaque fois que cela fait du sens.
Dans cette perspective, la consolidation de serveurs représente un scénario de peu d’ambition par rapport à ce que l’on va pouvoir réaliser dans le futur. Même si la consolidation de serveurs est bien évidemment un sujet important, ne serait-ce que dans une perspective de préservation de l’énergie. De même que l’utilisation de la virtualisation pour construire des plans de reprise d’activité, scénarios encore trop peu utilisés en environnement virtualisé.
Revenons maintenant à la comparaison de VMware par rapport à Windows Server Virtualization ou Hyper-V. Une des choses intéressantes dans Hyper-V sur laquelle on n’a probablement pas communiqué suffisamment, c’est que l’architecture de virtualisation est assez originale. Cette architecture est d’ailleurs partagée de façon assez significative avec celle de Xen, ce qui n’a rien d’étonnant puisque Xen a été pour une large part développé en collaboration avec Microsoft Research à Cambridge. C’est quelque chose que l’on ne sait pas mais il y a eu pas mal de contributeurs de MS Research sur le projet Xen.
C’est une architecture fondée sur un concept que l’on appelle généralement la paravirtualisation, à ceci près qu’Hyper-V ne nécessite pas un nouveau noyau pour les machines virtualisées. Ce qui signifie que l’on va architecturer le moyen de faire en sorte que, contrairement à tous les systèmes de machines virtuelles qui existent sur le marché, on puisse admettre qu’il y ait des échanges entre les machines virtuelles. On parle beaucoup de la virtualisation utilisée pour permettre l’isolation entre deux machines virtuelles. Je démarre Windows Server 2003, je lance Virtual Server qui me permet d’instancier une architecture x86 sur laquelle je vais démarrer la machine virtuelle que je cherche à héberger. Il s’agit d’une architecture classique qui ne repose pas sur un hyperviseur, ce qui en soi est un peu obsolète. Hyper-V est fondé sur une technologie de type hyperviseur mais va également reposer sur cette idée de paravirtualisation. Pourquoi est-ce important ? Un hyperviseur en tant que tel c’est une couche logicielle très fine qui va s’exécuter directement sur le hardware et dont l’objectif essentiel est de permettre de multiplexer les ressources entre ressources physiques (les CPU, la mémoire, les IO) et les ressources logiques, soit les différentes machines virtuelles que je vais héberger au dessus de mon hyperviseur. L’hyperviseur instancie l’architecture x86 et au dessus j’instancie « n » machines virtuelles. La différence dans l’architecture d’Hyper-V c’est que au lieu de faire simplement cela, on va, en fait, au dessus de l’hyperviseur, instancier une machine virtuelle un peu particulière que l’on va appeler machine virtuelle parente qui sera unique qui va exécuter un noyau minimal de Windows Serveur 2008 (la version « cœur » de Windows Server 20028 et une version encore plus « fine » avec Windows Server 7 qui s’appelle MinWin) et qui va autoriser l’exécution en parallèle de « n » autres machines virtuelles, appelées machines virtuelles filles et qui pourront être des machines de deux types. Soit des machines virtuelles « standard », soit des machines virtuelles paravirtualisées. Dans le cas d’Hyper-V, nous utilisons une approche que l’on pourrait appeler micro-hyperviseur puisque cette couche logicielle est de très petite taille (moins de 1 MO) contrairement à l’approche de VMware dont l’hyperviseur ESX représente aujourd’hui plus de 30 MO.
L’intérêt d’avoir des machines virtuelles paravirtualisées c’est qu’elles vont autoriser la communication avec d’autres machines virtuelles et en particulier la machine virtuelle parente. L’idée c’est que l’on a tout en bas l’hyperviseur, au dessus une machine virtuelle parente et toute une série de machines virtuelles filles. L’objectif de la communication entre les machines virtuelles filles et parente c’est que la machine virtuelle parente va permettre de résoudre un des problèmes majeurs que connaissent aujourd’hui tous les environnements de virtualisation qui est la pauvreté pathétique en support des entrées sorties. Je veux dire simplement qu’aujourd’hui toutes les entrées sorties se font vers des périphériques émulés. On va ainsi avoir une interface Ethernet, SCSI ou USB mais on ne va pas avoir accès à toute la richesse des périphériques qui est disponible dans l’environnement Windows. L’objectif recherché à travers cette paravirtualisation c’est de faire en sorte qu’à partir du moment où une machine est paravirtualisée, au moyen de l’installation d’une petite couche logicielle (appelée « enlightenment ») sur chacune de ces machines virtuelles, elles vont pouvoir discuter à travers un bus logiciel avec la machine virtuelle parente qui elle va offrir la richesse représentée par les dizaines de milliers de périphériques supportés en standard dans l’environnement Windows. Ca veut dire que l’on peut virtualiser l’interface vers un scanner, une imprimante, …
Cette capacité n’est offerte aujourd’hui par aucune machine virtuelle. Elle est très intéressante au niveau d’un serveur car elle va permettre un accès natif et direct aux drivers d’un SAN, d’un NAS ou à tous les drivers que l’on peut trouver sur un serveur. Dans une perspective d’utilisation sur un poste de travail, l’importance est encore plus grande. J’ai besoin d’avoir le vrai driver NVIDIA ou ATI, le vrai driver USB ou du scanner, …
Depuis une machine virtuelle fille, on va pouvoir émettre à travers ce bus logiciel une entrée sortie qui va être redirigée vers le vrai périphérique physique qui va communiquer avec le vrai driver supporté dans Windows. Ça veut donc dire que contrairement au fait de disposer en tout et pour tout d’une dizaine de drivers supportés en mode émulé dans l’environnement, qu’il soit VMware ou Virtual Server aujourd‘hui, on va pouvoir bénéficier de l’accès natif et immédiat à toute la richesse des périphériques présents dans Windows. Cela va permettre de répondre au problème de la pauvreté des périphériques dans un environnement virtualisé. C’est donc un élément fondamental qui différencie Hyper-V de ce qui existe aujourd’hui sur le marché, en dehors de Xen qui partage les mêmes fondements.
Le deuxième élément qui va arriver dans un futur proche c’est l’arrivée au niveau de l’architecture Intel et AMD d’extensions permettant de supporter la virtualisation non plus à travers une assistance concernant essentiellement le CPU et la mémoire comme cela existe aujourd’hui, mais à travers des extensions complémentaires qui vont permettre de faciliter la virtualisation des entrées sorties (extension appelée VT-d chez Intel).
Cela concerne le deuxième point qui à mon sens constitue un point extrêmement faible des architectures de virtualisation et qui est la performance des entrées sorties. Cette absence de performances constitue un frein puisqu’aujourd’hui on travaille uniquement au travers de l’émulation de périphériques et donc on n’a aucune assistance apportée par le hardware et on est obligé de tout faire par le logiciel. L’arrivée de ces extensions va permettre de faire ce que l’on appelle du DMA remapping qui consiste à dire que si je suis dans une machine virtuelle fille et que je cherche à faire une entrée sortie qui va de toute façon devoir être redirigée vers la machine virtuelle parente (c’est elle qui va effectivement avoir accès au périphérique), ce que l’on va faire c’est de lancer mon entrée-sortie dans ma machine virtuelle fille, ce qui revient à envoyer un message à ma machine virtuelle parente pour lui dire se préparer et en même temps je vais avoir une assistance hardware qui va me permettre d’indiquer la fenêtre vers laquelle je veux réaliser mon entrée-sortie dans ma machine virtuelle fille. Je vais la remapper (d’où le nom de DMA remapping) pour correspondre directement à la zone de mémoire physique vers laquelle est mappée le périphérique. Cela veut donc dire que depuis ma machine virtuelle fille, je vais avoir la possibilité de faire l’entrée sortie directement dans la zone mémoire physique qui m’intéresse. Je ne vais pas être obligé comme je le fais aujourd’hui de recopier des buffers entre ma machine virtuelle, la zone système dans laquelle je vais faire mon entrée sortie et ensuite le périphérique. Je vais pouvoir le faire directement sans passer par un quelconque échange. Je vais donc faire mon entrée-sortie dans ma machine virtuelle exactement comme je le ferais dans une machine physique, en dehors de la préparation de l’entrée-sortie à travers ce mécanisme de bus logiciel qui représente un coût extrêmement faible de quelques microsecondes.
Ce qui est très intéressant par rapport à ces extensions qui arrivent dans les chipsets d’Intel et d’AMD, c’est que cela ne concerne pas seulement le CPU mais le chipset que l’on trouve dans la carte mère. La conséquence c’est que cela va permettre d’avoir enfin de bonnes performances d’entrées sorties dans les environnements virtualisés. Aujourd’hui si on cherche à virtualiser un environnement base de données ou messagerie, on est en général assez déçu des performances parce que ces environnements sont très gourmands en entrées-sorties et que cela coûte énormément de puissance CPU que d’émuler ces entrées sorties dans les environnements de virtualisation actuels.
L’arrivée de ces chipsets va permettre d’avoir enfin des entrées sorties performantes dans un contexte de virtualisation. C’est là que toute la puissance de l’architecture d’Hyper-V arrive. On a à la fois le couplage d’un dispositif de virtualisation qui sait s’appuyer sur tous les drivers qui existent dans l’environnement Windows et, qui plus est, on peut enfin les utiliser intelligemment. C’est là ou l’on arrive à voir une approche de la virtualisation qui va permettre de répondre à la plupart des obstacles actuels qui sont les problématiques d’entrées sorties, à la fois parce que la richesse de périphériques virtualisés supportés est extrêmement limitée et d’autre part parce que, de toute façon, on a des performances qui ne sont pas au niveau où on les attendrait.
Voilà les différences qui correspondent à la fois aux évolutions du logiciel et en même temps à l’évolution du hardware. Ces chipsets en question seront disponibles avant la fin de cette année et ils vont être présents dès le début de l’année prochaine dans les premières machines chez les principaux fournisseurs de serveurs dans un premier temps et de PC par la suite.
VMware n’a t’il pas également comme objectif de supporter ces chipsets ?
B.O. : C’est un peu compliqué. Pour l’instant l’architecture des produits VMware n’est pas orientée dans cette direction là et, d’autre part, notre avantage est d’être dans un environnement Windows pour la machine virtuelle parente afin de bénéficier de toute la richesse des périphériques supportés dans cet environnement. Mais c’est sans doute un peu plus subtil que cela. Vous avez probablement vu les accords passés avec Novell qui comprennent la paravirtualisation. Cela se traduit par une couche logicielle qui va devoir être ajoutée aux machines virtuelles filles. C’est quelque chose que l’on va développer conjointement avec Novell pour permettre de pouvoir héberger Suse Linux dans un environnement paravirtualisé.
En fait, l’environnement dont on parle aura la possibilité de fonctionner dans un environnement non paravirtualisé. Donc, si j’ai un système d’exploitation RedHat qui n’est pas paravirtualisé, je pourrais sans utiliser ce dispositif de bus logiciel, fonctionner dans un mode qui est le même que celui qui existe aujourd’hui avec un Virtual Server à ceci près que ce sera un hyperviseur à la place. On pourra faire exactement la même chose mais on ne pourra pas bénéficier de ce dont j’ai parlé en matière de richesse de périphérique d’entrées sorties, de performance, … L’intérêt de ce mode, c’est que si l’on veut virtualiser un environnement Suse Linux dans un contexte Hyper-V, il y aura la possibilité de le faire de façon performante. L’idée c’est également de faire en sorte que Virtual Machine Manager soit en mesure de gérer des machines virtuelles qui soit aussi bien des machines virtuelles Windows que des machines virtuelles Suse Linux (ou VMware d’ailleurs) par ce que c’est ça qui intéresse le client. Le client cherche à gérer de façon homogène ses ressources qu’elles soient physiques ou virtuelles, que ces dernières soient Windows ou Suse Linux, à travers une interface commune.
S’agissant d‘Hyper-V, il s’agit là de la direction majeure vers laquelle on tend en sachant que cela s’inscrit dans une perspective beaucoup plus large que l’idée de pouvoir simplement consolider des serveurs ou de mettre en œuvre des plans de reprise d’activité.
Pour ces derniers on a une intégration complète des dispositifs de sauvegarde en ligne, de shadowing, de mirroring qui existent aujourd’hui et qui permettent d’avoir une réplication à distance de l’état des machines virtuelles de telle façon que si jamais l’on a un problème sur le premier Datacenter on sache redémarrer immédiatement le deuxième Datacenter.
Ce qui représente un des points forts de l’offre VMware, vous avez donc une offre équivalente.
B.O. : Oui, tout à fait, même si elle ne repose pas sur les mêmes outils mais globalement l’idée c’est de pouvoir faire ce genre de choses. Ce sont des scénarios qui sont encore peu mis en œuvre par les clients mais on peut considérer que ce sont des scénarios qui vont progressivement se généraliser dans les années qui viennent.
Cela permettra de démocratiser le disaster recovery
B.O : Oui, absolument. C’est à la fois plus simple à mettre en œuvre en ce qui nous concerne, par ce que plus simple à comprendre, et en même temps c’est efficace.
Il y a cependant un certain nombre de questions aujourd’hui qui ne sont pas encore résolues que ce soit chez nous, ou chez qui que ce soit ; en effet, dans un environnement de virtualisation, il y a un certain nombre de concepts de base qui changent, en particulier par ce que dans un environnement virtualisé on va avoir un certain nombre de machines virtuelles « dormantes », typiquement dans un environnement de reprise d’activité ou de disaster recovery.
Dans ce contexte on va avoir une machine virtuelle à distance servant de backup qui, en fait, ne va pas tourner. Un des sujets sur lesquels on a encore à progresser à mon sens c’est la dimension de ce que l’on pourrait appeler le « patch offline ». Aujourd’hui pour patcher une machine Windows on est obligé de la booter. En effet, tous les outils d’installation de patch nécessitent que la machine soit vivante (sauf dans l’environnement d’images système proposé par Vista : WIM). Et donc il est nécessaire de travailler sur des outils qui vont permettre de patcher des machines qui ne tournent pas. En partant du principe qu’une machine virtuelle est un gros disque dans lequel on va trouver plein de fichiers, patcher ça consiste essentiellement à remplacer des fichiers. En soi ce n’est pas très compliqué mais il n’y a aucun outil aujourd’hui qui soit disponible dans un environnement Windows et qui permette de le faire. On pourrait utiliser des outils permettant de modifier les fichiers contenus dans un .VHD, qui contient ma machine virtuelle, mais ce qui pose problème c’est la modification des données du registre de cette machine. C’est un travail que nous devons faire parce que personne d’autre n’est en mesure de le faire. Si Microsoft met à disposition des utilisateurs des patchs, il faut que ces patchs puissent être installables sur une machine qui est « off ». Aujourd’hui cela ne marche pas.
C’est un sujet auquel on ne pense pas encore, parce que cela n’est pas encore fréquemment mis en œuvre mais, quand on a un plan de reprise d’activité, il faut faire en sorte que l’on sache patcher la machine hôte qui va héberger le système, qu’on sache la mettre à jour, que l’on ait un plan de mise à jour des ces machines virtuelles dormantes.
On dispose malgré tout de solutions ponctuelles. Par exemple, dans un environnement cluster, j’ai un nœud virtuel et un nœud opérationnel. Je patche le nœud virtuel puis je bascule les traitements sur ce nœud que je viens de patcher, le temps de patcher l’autre nœud qui sera donc à son tour à jour. Il serait plus simple de savoir faire des mises à jour « offline » que de passer par ce dispositif qui n’est pas totalement transparent. Il serait préférable de pouvoir dire, quand un patch est émis, que l’on a mis à jour toutes les machines physiques, toutes les machines virtuelle opérationnelles et les machine virtuelle dormantes, plutôt que d’avoir à procéder comme on vient de le décrire. Ce serait beaucoup plus simple et satisfaisant en matière de gestion des configurations. Mais ça reste à faire.
Un autre concept intéressant rendu possible par la virtualisation est celui de Datacenter dynamique
B.O. : En fait ça va un peu petit peu avec. On a écrit beaucoup de choses sur ce sujet qui procèdent plus de la science fiction que de la réalité. Si on parle de Datacenter dynamique au sens où l’on peut dire : j’ai un certain nombre de machines virtuelles sur lesquelles je n’ai pas assez de puissance CPU, voire je n’ai pas assez de mémoire disponible, c’est quelque chose qui est effectivement rendu possible par la virtualisation sans aucune difficulté. Mais à mon avis, un vrai Datacenter dynamique va bien au-delà de ça. On raisonne ici très infrastructure, mais la vraie dynamique, elle, s’exerce au niveau des applications qui s’exécutent dans cet environnement là.
Avoir un Datacenter dynamique ça veut dire au départ que les applications ont été conçues pour pouvoir être managées, surveillées, opérées. Aujourd’hui si on est réaliste, sorti de la surveillance de quelques compteurs de CPU ou de mémoire, on ne va pas beaucoup plus loin. L’un des objectifs majeurs de l’initiative DSI (Dynamic Systems Initiative) c’est de faire en sorte que, dès la phase de conception des applications, l’on spécifie celles-ci comme étant manageables ; ainsi, autour d’une modélisation de l’application en production, on a la possibilité d’établir un dialogue entre la production et les études, dialogue aujourd’hui totalement défaillant dans l’immense majorité des entreprises.
Aujourd’hui, les applications sont souvent conçues en interne ou par l’intermédiaire d’un prestataire et sont ensuite confiées à la production en leur disant « débrouillez-vous ». Quand on regarde un Datacenter ce n’est pas juste trois quatre machines qui font tourner une base de données mais aussi très souvent un certain nombre de serveurs Web pour l’internet ou l’intranet. Il faut donc avoir la capacité de gérer à beaucoup d’endroits les problèmes de montée en charge. Problème : que se passe-t-il si je multiplie par deux le nombre d’utilisateurs ? A quel endroit cela va-t-il coincer ? Il faut que cette dimension remonte jusqu’aux applications et pas simplement considérer que j’ai dans mon Datacenter un certain nombre de processeurs et de la RAM supplémentaire. Ce n’est qu’une étape.
Les managements packs de SharePoint, Exchange ou SQL Server disponibles aujourd’hui pour System Center Operations Manager vont dans ce sens.
B.O. : Oui, on va dans cette direction. L’idée c’est de dire qu’autour d’une librairie de modèles on ait la possibilité petit à petit de savoir aussi bien manager, faire du capacity planning, être capable de remonter des informations qui correspondent à la connaissance de la production afin de mettre en place un meilleur management,…. Ça prend un peu de temps. DSI c’est une initiative que l’on a mis en place maintenant depuis quatre ans et les choses progressent petit à petit. En ce sens les nouvelles versions de la « vague 2008 » (Windows Server, Visual Studio, SQL Server) constitueront un progrès tout à fait significatif car supportant la modélisation, à travers l’utilisation de SDM (System Definition Model).
Où en est-on dans ce domaine avec les générations courantes d’application?
B.O. : Il y a maintenant dans les outils de développement toutes les briques de base qui permettent de développer des applications qui vont rentrer dans cette catégorie d’applications modélisables, mais rares sont les applications qui répondent aujourd’hui à ces critères.
Les managements packs que l’on peut trouver pour les applications serveurs de Microsoft ou d’autres éditeurs, correspondent à une première étape mais je pense qu’il va encore s’écouler probablement deux ou trois ans avant que l’on ne voie apparaître un vrai environnement capable, dès la phase de développement de pouvoir dire : j’ai une vision complètement modélisée de mon environnement, de mon infrastructure logique et physique. Quand je développe mon application, je vais être capable sur la base de ce modèle de simuler une mise en production, un déploiement de cette application. Et je vais pouvoir dès ma phase de développement, voir quelles sont les éventuelles contradictions qu’il y a entre les spécifications en termes de qualité de service de mon application et ce que j’ai mis en place dans mon infrastructure de production. Typiquement si j’ai un certain niveau de disponibilité attendue, il est probable que je vais avoir besoin par exemple soit d’un cluster, soit d’une ferme de serveurs Web et je vais pouvoir me rendre compte dès la conception de mon application qu’un certain nombre de règles que j’ai imposées en terme de qualité de service sont violées et donc faire les ajustements nécessaires dès la phase de développement. Il est clair que de développer une application qui va cibler un serveur Web et une base de données, ce n’est pas la même chose que de développer une application qui va savoir potentiellement fonctionner sur « n » serveurs Web en parallèle. En effet, on a alors une problématique de gestion des états. Si j’ai « n » serveurs Web et que je suis connecté depuis l’extérieur, il faut que j’aie la garantie que si j’ai commencé ma transaction sur un serveur Web et que je la continue sur un autre que je vais garder mon contexte de transaction. Cela a des impacts dans le développement des applications et je ne peux pas passer d’un serveur à l’autre par un simple claquement de doigts. A mon sens, un vrai environnement dynamique nécessite que ce caractère agile et dynamique soit pris en compte dès la phase de développement des applications.
Pour revenir à la question de la performance, comment peut-on estimer l’overhead lié à la virtualisation ?
B.O. : Honnêtement c’est assez difficile. Dans une application qui ne fait que du calcul et des accès à la mémoire on peut considérer qu’on est très, très proche des performances d’une machine physique. Dès qu’on commence à faire des entrées sorties, dès qu’on commence à faire beaucoup de changements de contexte, là le coût de la virtualisation devient de plus en plus lourd. C’est très difficile de caractériser ex nihilo les performances d’un environnement virtualisé. Typiquement virtualiser des environnements dans lesquels on fait peu d’entrées sorties, beaucoup de calcul, ça marche très bien. Dès que l’on veut virtualiser une grosse base de données, on a de temps en temps des surprises. En fait, ça marche mais le nombre de machines physiques qu’il faut pour virtualiser cet environnement n’est pas forcément dans le ratio machine virtuelle/machine physique que l’on avait eu l’habitude d’avoir pour d’autres applications.
Il vaut mieux raisonner par workload, de dire que pour tel type de charge de travail il va y avoir tant d’utilisateurs que l’on va pouvoir héberger sur une machine virtuelle vs. une machine physique, en évitant de raisonner de façon générique. Pour se faire une idée des performances, il faut considérer l’impact de la virtualisation sur son environnement propre.
On va trouver dans Windows Server 2008 de façon native un hyperviseur, peut-on imaginer une évolution similaire concernant Windows sur le poste de travail ?
B.O. : On peut tout à fait l’imaginer. Pour l’instant c’est sans doute un peu prématuré pour en parler en matière de politique de licence, mais il faut s’imaginer que la virtualisation sera absolument présente partout dans le futur. Je vais aller un cran plus loin, au risque de faire un peu de futurologie.
Aujourd’hui si on regarde les machines massivement multi cœurs on raisonne sur une base de présupposés qui est de dire que tous les cœurs sont symétriques, tous les cœurs jouent exactement le même rôle. Quand on instancie une machine virtuelle dans un Core Duo, ce sont deux processeurs identiques qui vont exécuter les mêmes fonctions, les mêmes instructions, … Dans le futur, je pense que cela va changer. A terme il y aura bien sûr des processeurs qui joueront le rôle de processeurs généraux, qui pourront exécuter un code d’hyperviseur, mais on peut imaginer qu’autour on aura des processeurs asymétriques qui n’implémentent pas les mêmes fonctions au niveau hardware que le cœur en question. Ces processeurs pourront être capable de remplir des fonctions spécifiques, typiquement des processeurs spécialisés sur le traitement du signal, ou sur certains calculs haute performance ou encore des processeurs spécialisés dans du chiffrement pour assister un processeur central à chiffrer et déchiffrer des trames qui arriveront en permanence en provenance du réseau ; parce que il faut imaginer que demain il n’y ait plus d’échanges qui ne soient chiffrés. Ou bien être capable de faire intelligemment de l’interprétation de balises XML et d’assister le processeur dans un contexte où l’on utiliserait de façon massive des services Web. C’est un premier type de désymétrisation des cœurs.
Un autre pourrait consister à se situer dans un contexte où l’on a une vraie problématique de dissipation d’énergie et où on veut produire des processeurs qui consomment moins d’énergie et donc qui en dissipent moins, des processeurs « verts » en quelque sorte. On pourrait donc avoir un cœur qui exécuterait l’hyperviseur, qui serait capable d’avoir des dispositifs hardware extrêmement sophistiqués comme par exemple de la prédiction de branchements, de l’exécution dans le désordre qui sont en fait aujourd’hui des fonctions présentes dans tous les processeurs modernes aujourd’hui. Ces fonctions représentent une quantité extraordinairement importante de transistors.
On pourrait imaginer que certaines fonctions telles que celles énumérées plus haut n’existent pas dans des cœurs qui n’exécuteraient que des machines virtuelles qui n’ont pas forcément besoin de toute cette sophistication. On pourrait imaginer d’avoir un processeur multi-cœur hybride avec un cœur ou deux capables d’exécuter l’hyperviseur, tous les autres étant moins « haut de gamme » en termes de fonctionnalités hardware implémentées dans le processeur et eux dédiés uniquement à l’exécution de machines virtuelles. L’avantage de cet environnement c’est que l’on aurait peu de pertes en termes de performances ; par contre on aurait un gain colossal en termes de dissipation calorifique dans un contexte où la dissipation de chaleur dans les Datacenter devient un vrai souci.
Dans les méga Datacenter, tels que ceux de Google ou les nôtres, cette question est devenue un vrai cauchemar. On est obligé de se rapprocher des centrales électriques pour éviter d’avoir de la perte en ligne. Si on regarde ce qui se passe chez un certain nombre de nos gros clients qui ont des Datacenter, aujourd’hui la problématique de la quantité de courant et de la dissipation est devenue un vrai souci. Il y a eu une augmentation vertigineuse du nombre de serveurs qui ont été installés. Si on prend le cas des banques, il y a presque quatre ou cinq ans, ces entreprises ne faisaient pas de la simulation numérique massive; ce qu’elles font aujourd’hui pour être capables de simuler l’impact de telle ou telle condition du marché sur leurs positions bancaires. Aujourd’hui toutes les banques doivent, parce que c’est la réglementation qui l’oblige, disposer par rapport à l’état de leurs positions chaque jour de ce que serait leur position si se produisait l’équivalent d’un vendredi noir puisque les banques doivent en principe disposer des fonds propres leur permettant de se couvrir quels que soient les événements.
Aujourd’hui elles en sont à avoir des réunions hebdomadaires sur le sujet de la consommation énergétique. Depuis des années qu’elles rajoutent des serveurs, à un moment cela ne va plus, elles en sont à considérer l’opportunité de changement de génération de serveur simplement pour réduire leur consommation électrique. C’est une question que l’on se posait pas il y a quelques années où l’on avait quelques très gros calculateurs, refroidis par eau, comme pour certains mainframes mais aujourd’hui on en a beaucoup. Dans la réalité la somme de toutes ces machines devient très difficile à refroidir. De plus en plus de recherche sont effectuées au niveau des serveurs « en lames » pour optimiser la circulation d’air et donc le refroidissement. Des marchés comme ceux là sont des marchés nouveaux qui constituent une aubaine pour les fabricants de hardware.
La virtualisation devrait avoir des conséquences sur les ventes de serveurs
B.O. : La virtualisation va avoir des conséquences certaines sur le nombre de serveurs vendus, ceci étant si le volume est amené à diminuer l’expérience prouve que les marges que dégagent les constructeurs sur des serveurs haut de gamme sont généralement bien supérieures aux marges des serveurs d’entrée de gamme. Ce que les constructeurs perdent en volume, ils devraient le retrouver en marge.
Pour revenir à Windows, le mouvement vers la virtualisation n’a-t-il pas pour conséquence de rendre le système d’exploitation moins important ? Quel impact cela pourrait-il avoir sur le futur de Windows ?
B.O. : En fait, je vois pour ma part un impact extrêmement positif. Le système d’exploitation dans un environnement virtualisé aujourd’hui existe toujours. Ce que l’on virtualise c’est un environnement complet dans lequel le système d’exploitation continue son rôle en tant que tel. Sur ce plan il n’y a pas de remise en cause.
Ce qui me paraît très intéressant dans la virtualisation c’est que, dans une perspective moyen terme, ça va nous permettre de faire évoluer Windows de façon absolument majeure. Tout simplement parce que, en partant de la logique que je décrivais qui repose sur la possibilité d’isoler les dépendances entre le système d’exploitation, le middleware et les applications, cela apporte une très grande agilité au niveau de nos clients mais, pour nous, cela va apporter la possibilité de pouvoir potentiellement ne plus avoir à payer le prix de la compatibilité avec le passé.
Autrement dit cela va nous permettre potentiellement à la fois de laisser de côté un certain nombre de vieilles API qui n’existent que pour assurer la compatibilité avec des applications qui ont été écrites du temps de Windows 3.0, voire avant, qui n’ont plus de raison d’être et que nous sommes obligés de maintenir par ce que nos clients nous le demandent, et en même temps on peut imaginer un système d’exploitation qui serait résolument différent des versions précédentes de Windows, avec une architecture totalement différente. Faire cela aujourd’hui est extraordinairement compliqué par ce que l’on doit s’assurer que toutes les applications continuent de tourner.
Si demain, le système d’exploitation nouveau est là, s’il sait virtualiser les anciens systèmes d’exploitation de manière transparente et intégrée pour les utilisateurs alors les choses deviennent beaucoup plus simples.
Aujourd’hui l’expérience de la virtualisation est très pauvre. Quand on veut activer une application, on démarre une machine virtuelle. Demain, on voudra démarrer une nouvelle application. Le fait que cette application repose sur une machine virtuelle sous-jacente n’est pas la question de l’utilisateur. Il n’a aucune idée de ce qu’est une machine virtuelle. L’interface est très pauvre. Ce qu’il faut c’est qu’à travers une intégration avec le shell, d’une façon dynamique quand on active une application, la machine virtuelle sous-jacente démarre sans que l’utilisateur s’en aperçoive. Il ne faut pas que l’utilisateur soit dans un bureau différent. Pour l’instant cela n’est pas le cas.
Dans un environnement tel celui que je décris, dans lequel on a résolument changé de système d’exploitation on peut imaginer une intégration totalement transparente de la virtualisation. Finalement pour l’utilisateur, il lance son application; dynamiquement la machine virtuelle instancie Windows 95, NT 4.0 ou que sais-je. La machine virtuelle est lancée, l’utilisateur continue à utiliser son application et de notre côté cela nous a permis de ne plus être freinés par la compatibilité avec tout le passé. Ce qui est vrai pour l’ensemble de nos clients, à savoir la possibilité de faire évoluer leur système d’information de façon beaucoup plus agile en fonction de leurs besoins plutôt que d’attendre de mettre tout au même palier technologique, s’applique également à notre activité. Pour nous, la virtualisation c’est un énorme potentiel.
Aujourd’hui, si on prend Vista en tant que tel. Le principal frein à son adoption c’est la compatibilité applicative. On a fait un certain nombre de choix dans Vista, par exemple le nouveau mode de sécurité, l’UAC, pour prendre cet exemple là, qui casse la compatibilité avec de nombreuses d’applications. Il s’agit d’un choix conscient de notre part. Par contre l’inconvénient est que la vitesse d’adoption de Vista s’en trouve ralentie. Si on peut réussir de ne plus à avoir à payer le prix de la compatibilité avec le passé, ça peut nous permettre nous d’aller beaucoup plus vite et de ne pas avoir à embarquer des centaines d’API plus ou moins obsolètes.
Si on essaye de se projeter dans un avenir où le système d’exploitation est dérivé de singularity « * » par exemple. Dans un tel environnement, le système d’exploitation écrit exclusivement en code managé et toutes les applications seront aussi disponibles en code managé. Pour nous, les seules API qui resteront dans un tel environnement sont les API du Framework .NET. Toutes les API Win32 on aurait envie de les faire disparaître entièrement, de A à Z. Aujourd’hui c’est strictement inimaginable. Il n’y aurait plus rien qui marcherait. Ça c’est quelque chose qu’aujourd’hui on ne peut pas faire. Dans un contexte où la virtualisation est devenue généralisée cela devient possible. C’est la raison pour laquelle la virtualisation est si importante.
« * » voir http://research.microsoft.com/research/pubs/view.aspx?tr_id=989
Ce que vous décrivez là ne s’applique pas à Windows 7 mais concerne une perspective de long terme.
B.O. : Cela va en effet mettre quelques années mais ce qui est intéressant c’est que le hardware arrive, les technologies de virtualisation deviennent vraiment mâtures. On peut imaginer et cela ne peut pas être fait avant, qu’on sache virtualiser tous les environnements, y compris ceux riches en entrées sorties ce qui est capital car dans un environnement poste de travail, en particulier sur un portable, les entrées sorties sont devenues un vrai problème. Les disques durs ne vont passez vite, l’utilisateur est en permanence en train d’attendre ses données. Si on virtualise en plus cet environnement avec les conséquences sur les entrées sorties, cela devient une catastrophe. En fait, c’est une des raisons pour laquelle sur un portable il est nécessaire de disposer d’une vraie assistance hardware pour la virtualisation des entrées sorties.
A contrario, ne pensez vous pas que les bénéfices de la virtualisation risquent d’être contrebalancés par un niveau de complexité plus important concernant l’architecture applicative du poste de travail ?
B.O. : En fait, l’architecture du poste de travail va devenir beaucoup plus simple. Regardez aujourd’hui la complexité du poste de travail. Elle est liée à la difficulté de la gestion du cycle de vie de ce poste. Celle-ci se décrit par : j’installe un nouveau poste, je crée un nouveau master et puis je fais vivre tout ça avec les évolutions des applications, du middleware, des service pack, … jusqu’à la fin de vie du poste de travail en question. Cet aspect là est devenu extrêmement problématique même s’il y a eu des progrès significatifs avec Vista en matière de déploiement, l’introduction d’un master unique,… ce n’est pas encore suffisant.
Si on regarde juste les capacités de la virtualisation applicative, de notre offre SoftGrid, la capacité à pouvoir encapsuler dans un container une application, ses dépendances avec le middleware et le système d’exploitation. L’intérêt de ce dispositif c’est que si j’essaye de me projeter dans un contexte où je suis capable de virtualiser toutes mes applications, ce qui est vrai dans pratiquement 100 % des cas, le poste de travail dans ce contexte va être extrêmement simple.
Je vais installer sur ce poste de travail : Vista, un client SoftGrid, potentiellement un client SMS (désormais System Center Configuration Manager) et c’est tout, rien d’autre. J’ai un poste de travail extraordinairement banalisé et simple, facile à reconstruire. Ça me permet de me connecter sur un portail où en fonction de mon appartenance au groupe dans lequel je suis, par exemple dans le groupe RH par exemple, je vais pouvoir installer un certain nombre d’applications qui correspondent à mon rôle. Je vais me connecter sur ce portail et je ne verrais que les applications qui me concernent, je vais cliquer sur l’icône d’une application et je vais streamer cette application sur mon poste de travail. Je vais pouvoir commencer à l’utiliser dès qu’il y a suffisamment de bits sur mon poste de travail de telle façon que mon poste dépende de mon rôle dans l’entreprise et qu’il n’y ait pas un master unique pour la terre entière. J’ai des applications qui correspondent exactement à mes fonctions, à mes besoins, disponibles via un portail sur lequel l’IT exerce un contrôle complet mais où en même temps, sur le poste de travail j’ai enfin de nouveau quelque chose de simple. Pour le reconstruire j’ai juste besoin d’avoir mon master avec Vista, le client Configuration Manager et le client SoftGrid et c’est tout. Je me connecte au serveur, je rapatrie tout ce dont j’ai besoin.
La virtualisation dans ce cadre là c’est une simplification extraordinaire du poste de travail. Ça vaut même et y compris pour Office.
Dans ces conditions à quoi sert-il d’avoir un registre au niveau du système d’exploitation ?
B.O. : En l’occurrence, effectivement le registre dans un environnement tel que celui là va servir à gérer la configuration du système et à gérer la configuration des applications que l’on va vouloir pour une raison ou une autre installer en dur sur le poste de travail. On pourrait dire, j’ai 99 % des mes utilisateurs qui utilisent Word, je vais donc l’installer en « dur » sur les postes de travail. Le reste va dépendre de leur rôle.
L’intérêt c’est d’éviter que tout le monde ait besoin de télécharger une application donnée parce que tout le monde l’utilise et que l’on pourrait très bien la masteriser. Dans beaucoup de cas, quand on regarde la configuration des masters dans la plupart des entreprises, on essaye de définir une espèce de socle commun entre « n » divisions, « m » business units, … et dans la plupart du temps sur le master on va trouver quarante, cinquante, cent applications ce qui est beaucoup trop.
On arrive à un niveau de complexité énorme. Ces applications ont ensuite besoin de vivre, chacune indépendamment. On est obligé de les patcher, de les mettre à jour. Là, l’idée consiste à dire que si j’ai une nouvelle version de mon application, elle apparaît en central sur le portail. Par rapport à la version qui est « cachée » sur mon poste de travail je fais la comparaison, je m’aperçois qu’une nouvelle version est disponible en central. C’est exactement le principe de ClickOnce dans un environnement .NET avec la différence qu’en ce qui concerne .NET il y a un Framework, ici on parle d’applications qui existent et qui correspondent au patrimoine de millions de clients qui ont développés ces applications au cours du temps et qui ne seront jamais réécrites en .NET.
Ce qui est intéressant derrière ce modèle, c’est qu’au-delà d’un modèle technique il y a aussi un business model. Si on est capable de consommer des applications à la demande, on est aussi capable potentiellement de facturer la consommation de ces applications. On est en face d’un autre business model qui reste à inventer. Ce n’est pas un sujet sur lequel on pourra s’étendre mais il est évident que ce modèle là on peut le transposer sur l’Internet.
Nous parlions la dernière fois de Software plus Services. Quel plus beau modèle qu’un environnement dans lequel sur un poste de travail quelconque on a un client SoftGrid, on dispose d’un Datacenter sur lequel on sait télécharger toutes les applications de Microsoft ou de ses partenaires, on sait facturer ces applications à la consommation et on sait derrière adresser la facture au client. Si on sait faire cela, on a à mon sens résolu tous les problèmes.
Software plus Services cela pourrait être cela, pour l’instant ce n’est que du conditionnel.
Le maillon manquant réside dans la facturation
B.O. : Oui mais il s’agit aussi d’un changement profond de business model. Aujourd’hui quelqu’un qui achète un logiciel a un droit perpétuel d’accès à la licence. Il peut utiliser ce logiciel au moins en théorie éternellement.
Cela permettrait de découpler le droit d’utiliser un logiciel de la machine sur laquelle il est installé et donc d’utiliser le même outil quelle que soit le poste de travail que l’on utilise.
B.O. : Oui, c’est intéressant dans un contexte d’usage multi machines mais aussi si j’imagine que je suis à la maison et que j’ai seulement besoin d’Excel quinze jours par an pour faire ma déclaration d’impôts.
C’est un scénario d’usage qui peut faire du sens. Derrière c’est une remise en cause très profonde de la façon dont on a commercialisé des logiciels depuis toujours. Je reste persuadé que cette évolution sera nécessaire mais… ce n’est que mon avis.
