À propos de la virtualisation applicative

Cloud computing & virtualisation

[Je parle surtout des technologies de VMWare mais cela est généralisable aux autres solutions]

Le Cloud Computing se définit comme une démarche de mise à disposition, via un accès internet, à des ressources de différents niveaux : infrastructure (IaaS), plateforme de développement (PaaS), services applicatifs (SaaS).

Cette logique est publique en ce que les clients de telles offres partagent une infrastructure commune et mutualisée en louant des ressources dont ils ne sont pas propriétaires. Les mécanismes de location sont à la fois “à la demande” et automatisée en self-service, sans nécessité de passer par des intermédiaires commerciaux : une interface d’administration web permet tout à la fois de commander des services, de les configurer, de les gérer et aussi de les arrêter.

La logique de virtualisation des infrastructures est à a base d’une démarche de Cloud Computing, et c’est en ce sens qu’une entreprise qui se lance dans une logique de virtualisation de ses propres infrastructures peut prétendre mettre en place un Cloud Privé ou Interne. Mais cela ne suffit pas pour autant car, si la virtualisation apporte de la souplesse et une meilleure optimisation de l’infrastructure, elle n’offre pas pour autant une approche self-service couplé à une facturation à la demande.

C’est l’enjeu des offres vCloud de VMware d’étendre son offre de services de virtualisation (VSphere) à une logique de self-service basée sur un catalogue avec une logique de re-facturation (entre services internes).

Virtualisation physique et virtualisation Applicative

Si tous les acteurs de Cloud Computing mettent en oeuvre des stratégies de virtualisation des couches physiques (serveurs, CPU, mémoire, etc.) et bases (Système d’exploitation), ils ne vont pas pour autant jusqu’à virtualiser des environnements applicatifs, préférant déployer des architectures applicatives distribuées s’appuyant sur des systèmes de redondance des données entre différents centres de données.

Cette démarche de virtualisation des infrastructures s’est effectuée, comme dans la plupart des DSI en France, sans que cela n’impacte les différentes couches applicatives. Et il n’est pas rare de constater que cette virtualisation des couches bases et matérielles (la couche physique) se soit faite sans même que les responsables applicatifs et les utilisateurs ne s’en soit aperçus.

Or à présent on constate des initiatives de virtualisation non seulement de ces couches basses mais également des couches applicatives.

Les opportunités de la virtualisation applicative

Il faut tout de suite préciser que, même si le marché actuel est dans une phase de croissance dans la mise en oeuvre de virtualisations non plus des infrastructures mais des applications, ce marché n’est pas pour autant mature : la plupart des grandes DSI françaises en sont au stade d’expérimentation et de prototypage de la virtualisation applicative et de sa mise en oeuvre sous forme de “Cloud Interne”.

La virtualisation applicative offre des pistes intéressantes concernant les points suivants :

  • réduction des cycles de validation et de mise en production des applications ;
  • portabilité des applications historiques (legacy) dans de nouveaux environnements ;
  • un meilleur “time-to-market” pour de nouvelles applications ;
  • une automatisation des processus existants ;
  • une amélioration de la qualité de service et de la continuité de service

Ces opportunités doivent néanmoins être éprouvées sur certains points pour lesquels les retours d’expériences manquent : robustesse, maintenabilité, performance et sécurité. A cela il faut rajouter la partie organisationnelle et fonctionnelle qui bousculent les processus existants des DSI ainsi que les emplois et les compétences qui lui sont associées.

Comment mieux accompagner le cycle de vie des applications ?

C’est autour de la question du cycle de vie des applications et de leur mise en production que les débats autour de la virtualisation et par extension autour du Cloud se pose au sein des DSI des entreprises.

Certains cabinets d’analystes, notamment le Gartner, on fait état de gains potentiels dans l’approvisionnement et dans les délais de mise à disposition dans les stratégie de virtualisation, mais aussi  dans le déploiement. C’est en partie de ce qui motivé les DSI à s’engager dans une démarche de virtualisation de leur portefeuille applicatif.
Aujourd’hui, on constate un cycle de mise en production qui passe successivement par :

  • une première installation par la TMA
  • plusieurs installation sur la plateforme de pré-production pour la recette, l’homologation, la qualification, ..
  • enfin une dernière installation pour la mise en production.

Ces réinstallations successives peuvent prendre plusieurs semaines et les “métiers” ne supportent plus ces longs cycles de validation qui à leurs yeux ne représentent que des contraintes et des coûts qui se justifient de moins en moins.

La logique de réinstallation de type “Wipe & Load”

Avant de développer l’option de la virtualisation et du Cloud (interne ou externe), envisageons une première option, défendue généralement par ceux qui sont en charge des couches mutualisées de infrastructure.

La logique de virtualisation repose sur l’encapsulation de tout un environnement applicatif dans une machine virtuelle (VM). Celle-ci pourrait alors circuler dans différents environnements et sur différentes plateformes (y compris une plateforme externe).

Or cet idéal se heurte à certaines réalités, parmi lesquelles :

  • si dans le fichier *.ini de telle application il y a écrit “en dur” qu’il faut telle machine, cela ne passera pas si la VM n’est pas dans l’environnent d’origine
  • il restera des traces dans le registre et un peu partout : l’encapsulation a donc de fortes de fortes limites.

Ainsi tout ce qui est écrit en dur : les adresses IP, l’accès au machines, aux bases (Bases de données, Annuaire, etc.) tous cela ne disparaît pas dans les VM et même dans les Vapp (qui ne suppriment pas les les clés dans le registre).

On peut comprendre les réticences de l’opérateur en charge de la plateforme quand quelqu’un veut pousser une VM dans l’environnement dont il a la charge et il ne manque pas de dire : “les mises en production c’est moi qui m’en occupe”.

S’il y a des GPO (pour Group Policy Object dans l’environnement Windows), avec la virtualisation on ne les annule pas, donc on cumule les GPO précédentes ; certes pour l’administrateur du poste de travail tout marchera mais pas pour l’utilisateur lambda. Donc ce qui va marcher avec dans l’environnement de TMA par exemple, où il y a tous les pouvoirs et droits, en marchera plus en production avec les utilisateurs.

Il peut également exister des cas bien pire que le simple constat “çà ne marche pas”. Ainsi la démarche qui consiste à transférer des VMs dans des environnements et des plateformes différentes peut “en apparence” parfaitement marcher. Mais en réalité les accès peuvent être faussés : par exemple une application en VM qui attaque non pas la base de production mais de pré-production. Ce genre de risque n’est pas sérieusement pris en compte dans la démarche qui consiste à “balader des VM dans des environnements différents”.

On perçoit bien que l’enjeu de l’acceptation des technologies de virtualisation passe par la question des adhérences et des adressages. Les technologies de virtualisation ne permettent pas  de gérer automatiquement et efficacement l’ensemble des adhérences d’une application à son environnement (réseau, OS, middleware et applicatif).

Pour autant, si l’on ne passe pas par la virtualisation pour automatiser la gestion du cycle de vie des applications, y a t il une autre solution ?

L’automatisation peut marcher si l’on repart toujours de zéro, il ne faut pas faire circuler les VM avec des historiques qui sont trop lourd et peuvent être des bombes à retardement. Il faut automatiser les logiques d’installation avec la possibilité de pouvoir toujours revenir en arrière si nécessaire.

L’installation automatique n’est pas la même chose que de faire circuler des VM dans des environnements distincts. Il s’agit de se mettre dans une logique de “wipe and load” (on efface et on recharge) : on repart de zéro avec un livrable qui est un exécutable qui s’installe automatiquement et dont on est sûr de la qualité sachant qu’on ne transfère que la configuration de l’application et pas son l’historique. Du coup, d’un point de vue réseau on ne transfère qu’un fichier de quelques kilo-octets de configuration et pas des VM de plusieurs dizaines de Gigas Octets, ce qui soulagne grandement les limitations de bande-passante qu’on les entreprises.

Cette approche a une part évidente de vérité, mais elle se heurte à une dure réalité concernant les applications les plus critiques du portefeuille aplicatif. Certaines applications sont un véritable mille-feuilles de sédimentation technologique avec parfois plusieurs dizaines de niveaux patchs qui obligent à regarder la réalité en face : certaines applications ne sont absolument pas reconstructibles et réinstallable.

L’approche “Wipe & Load” est peut-être la meilleure solution dans un environnement applicatif dont la complexité est maîtrisé, ou pour de nouvelles applications, mais elle n’est plus opérante pour la prise en compte du Legacy Applicatif, notamment pour les progiciel métiers.

La virtualisation poussée en mode Cloud : les opportunités de la technologie vCloud de VMware

Concernant le parc applicatif qui, pour des raisons de sédimentation informationnelle et de complexité des niveaux de patchs ne peut pas être réinstallé, les entreprises se retrouvent dos au mur. Ce qui a été fait, c’est une image de l’application qui la fige et la sauvegarde, mais une telle image ne peut être redémarreée que dans un environnement “à l’identique” : mêmes CPU, mêmes drivers, etc., ce qui est très contraignant et qui confirme la criticité de la situation.

La promesse de vCloud est de porter les logiques de virtualisation à un niveau d’abstraction encore plus poussé que la simple virtualisation applicative. Ainsi la technologie VMware (comme d’autres) est-elle sensée apporter des solutions aux problématiques d’adhérence des applications évoquées précédemment : encapsulée dans une vApp, une application pourrait être déplacée dans n’importe quel autre environnement vCloud.

Tout n’est pas encore figé et les solutions de VMware sont en pleine évolution. Ainsi le déplacement des VMs avec les vApp nécessite encore de changer à la main certains paramètres d’adressage : IP, accès DNS, machines, bases, etc.

Dans l’approche autour de la mise en place de vCLoud au sein d’une entreprise, la méthodologie suivante émerge :

  • Constitution d’un catalogue de souches virtualisées des technologies utilisée par l’entreprise ;
  • Les développeurs utilisent ces souches qu’elles choisissent dans le catalogue pour construire et faire évoluer les applications ;
  • Une procédure de re-construction de l’application en utilisant les éléments du catalogue vCLoud est réalisée (pour les applications critique on fait passer la VM dans les différents environnements sans les re-contruire) ;
  • Une application peut ainsi être théoriquement déplacée dans plusieurs vLCoud internes de l’entrerprise mais également dans un vCloud externe ;

On peut considérer métaphoriquement la technologie vCloud comme un “tapis roulant” qui permet de faire naviguer les vApp (les VMs des applications avec leur couche réseau virtualisée) sur différentes plateformes (interne et externes) qui sont certifiées “vCloud”.

Le recours à une offre Cloud IaaS externe sous un nouvel éclairage

Tout d’abord il faut noter que les offres de vCloud Externe sur le territoire français se résument à ce jour à l’opérateur/hébergeur COLT qui est le seul a posséder les accréditations et la certification de VMWare (OVH est en discussion et devrait obtenir la certification).

Ensuite, ces offres externes ne contiennent pas des souches virtualisées de technologies propriétaires (ex : weblogic) et privilégient des technologies Open Source qui ne sont pas communes chez les “grands comptes”.

Enfin, le mode de virtualisation adopté par les entreprises privilégie le maintient des données applicatives dans le périmètre des plateformes qu’elle opère : c’est le cas des bases de données, des logs mais aussi des annuaires. Ce qui implique qu’une vApp placée chez un opérateur externe devra faire des appels et des écritures dans un environnement vCloud de l’entreprise : tout ceci pose de réelles questions de performance.

A ces questions se rajoutent des questions de sécurité et d’ouverture de VPN entre l’entreprise et un partenaire externe. Même si la solution est théoriquement sécurisée (étanchéité logique des réseaux dans l’environnement mutualisé du prestataire externe), cela induit une réelle méfiance de la part de l’opérateur de plateforme qui y voit également une stratégie de contournement de son rôle au sein de l’entreprise(“on me vole mon job en essayant de me court-circuiter”)

Dissensus et Consensus au sein des Entreprises

On constate vite que les responsables des couches applicatives, proches des préoccupations des métiers, se sentent freinés dans leur appétence à virtualiser non plus la couche infrastructure mais celle des applications.

En dessous de la ligne applicative, responsables de la sécurité, responsable des plateformes et responsables infrastructure & réseaux freinent des quatre fers. On peut imaginer que la solution ne sera pas “tout virtualisé” car chaque application va avoir une trajectoire de virtualisation qui sera différente des autres, mais il me semble inévitable de virtualiser notamment les grosses applications métiers que plus personne ne saurait redémarrer en cas d’incident majeur. C’est donc sous la contrainte de leur patrimoine applicatif que les entreprises avancent et tentent d’instruire des arbitrages de virtualisation.

Cher Christian,

Le problème pour virtualiser les applications ne vient-il pas du fait que ces dernières ont trop de choses codées « en dur » ? D’après ce que tu dis, il me semble que cette virtualisation serait plus facile si tous les paramètres disons « de configuration » (adresses IP, etc) étaient stockés comme les autres données manipulées par l’application, non ?

[Reply]

Oui bien sûr., mais il y a toujours ce satané historique qui n’est pas forcément en Java et modèle MVC.
Tu peux toujours mettre l’ensemble d’une application dans une vApp en faisant en sorte qu’elle tourne en fait en local sans accès à des ressources externes mais çà va être une grosse pagaille en synchronisation.

[Reply]

Par historique, tu entends bien quelque chose comme « les données précédemment utilisées par l’application » ? si oui, à charge à l’application de gérer la migration des anciennes données vers un nouveau format s’il a changé, non ? c’est trop facile de faire table rase du passé, c’est même de la triche 🙂

[Reply]

 

Répondre à Jérôme Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.