Publié par

Il y a 10 années -

Temps de lecture 5 minutes

Pourquoi VMWare / SpringSource ? Virtualisation matérielle vs. Cloud

Pourquoi VMWare a racheté SpringSource dont le métier et la culture sont si différents ? Pourquoi un tel prix ?

Mon analyse est que VMWare a racheté SpringSource parce que le cloud computing de forme Platform As A Service (PaaS) à la Google App Engine va bientôt mieux répondre que la virtualisation matérielle aux besoins d’optimisation des data centers Java. Selon l’adage « Si quelqu’un scie la branche sur laquelle je suis assis, mieux vaut que ce soit moi », VMWare s’est dotée de l’expertise de SpringSource sur Tomcat et Hyperic.
Je parlerai des applications Java légères (Servlets, JDBC, JPA et JMS) qui sont aujourd’hui largement majoritaires dans nos data centers Java. Billy Newport, IBM WebSphere, reconnait qu’elles représentent 80% des cas, SpringSource aurait sûrement des chiffres plus élevés.

Optimiser la CPU des data centers

Les data centers débordent, l’électricité manque, les climatisations saturent, les planchers s’effondrent, les racks sont pleins et pourtant, les serveurs ne font rien, les CPU ne sont utilisées qu’à quelques pourcents !
La virtualisation matérielle, dont VMWare est un des leaders, propose d’adresser ce problème en introduisant une couche d’abstraction appelée hyperviseur entre le matériel et le système d’exploitation : plusieurs instances de système d’exploitation s’exécutent ainsi sur la même machine.
Considérons 10 serveurs qui consomment chacun en moyenne 5% de CPU, la virtualisation matérielle permet de les regrouper sur une seule machine physique qui atteindrait alors un taux d’utilisation de l’ordre de 50%. Malgré la chute du prix de la RAM, la mémoire vive de ce serveur mutualisé risque fort d’être insuffisante, l’hyperviseur règlera ce problème en recourant à la pagination de la mémoire (swap) comme un système d’exploitation le fait déjà à son niveau.
Et si par malheur ces serveurs venaient à être sollicités en même temps et à saturer la machine qui les héberge, les solutions de virtualisation parviennent maintenant à déplacer certaines instances sur d’autres serveurs physiques de façon transparente, sans même arrêter le service.

Les atouts de la virtualisation matérielle

Un atout essentiel de la virtualisation est le très faible coût d’adaptation des applications existantes puisqu’elles continuent à s’exécuter sur le même système d’exploitation avec le même voisinage. La virtualisation matérielle est transparente pour les applications, elle n’exige pas de changement de version du système d’exploitation, des librairies utilisées, des répertoires de travail ou des ports d’écoute.
Si une application est tellement exigeante qu’elle requiert une version de système d’exploitation dépassée ou qu’elle a été compilée avec la version très ancienne d’un driver de base de données, ce n’est pas grave. La virtualisation matérielle maintiendra cette application revêche isolée dans sa bulle et elle sera mutualisée comme les autres.
Un autre atout de la virtualisation est l’adaptation de la CPU et de la RAM allouée à chaque application selon ses besoins. De la même façon qu’un système d’exploitation sait allouer du temps CPU et de la RAM à une application qui a un pic d’utilisation, l’hyperviseur sait privilégier une instance parmi toutes celles qu’il exécute simultanément. Considérons 20 applications qui s’exécutent chacune sur un serveur bi-processeurs, la virtualisation matérielle permet de les regrouper sur un seul serveur quadri-processeurs et en cas de pic, allouer quatre processeurs à une seule application, le double de ce qu’offrait la solution non virtualisée.

Les limitations de la virtualisation matérielle pour Java

La première limitation de Java à la virtualisation matérielle est la gestion de la mémoire par les machines virtuelles. Les JVM assument que toute la mémoire qu’on leur alloue est en RAM, elles accèdent indifféremment à tout cet espace mémoire et le parcourent intégralement très souvent pour les garbage collections. De ce fait, la performance des applications Java s’effondre dès que leur mémoire est paginée. Pire encore, certains composants comme les timers des caches ou des gestionnaires de transactions échouent lorsque les temps de réponse sont anormalement longs et les applications tombent alors en erreur.
Ce problème est d’autant plus crucial pour la virtualisation matérielle que, du fait des techniques de garbage collection, les JVM libèrent peu de mémoire quand les applications sont moins utilisées.
Par ailleurs, l’adaptation à l’exécution de la CPU et de la RAM allouée à chaque application selon ses besoins est inadaptée en Java.
Le premier point bloquant est que l’espace mémoire utilisé par une JVM est défini au démarrage (Xmx) et ne peut changer lors de l’exécution. Ensuite, augmenter la puissance de traitement d’une application web Java nécessite non seulement d’allouer de la CPU et de la RAM, mais aussi de redimensionner les pools de threads http ou de connexions à la base de données ainsi que la taille de nombreux caches applicatifs (sessions http, objet venant de la base, etc).
Il faudrait donc que l’hyperviseur change les configurations Java, cela nécessite aujourd’hui d’interrompre le service pour redémarrer les applications. La promesse de transparence de la virtualisation matérielle devient caduque, le palliatif est d’avoir des middlewares qui interagissent avec la virtualisation matérielle.

Mutualisation en Java : De simples serveurs Linux-Tomcat suffisent

Si certaines applications sont revêches à la mutualisation, Java fait plutôt preuve de très bon voisinage.
Une application Java est quasiment agnostique du système d’exploitation et des libraires qui l’entourent, il lui suffit d’un répertoire pour ‘dezipper’ une JVM (<20 Mo), un moteur d'exécution (Tomcat < 5 Mo) et l'application. Cette facilité d'installation est utilisée au quotidien. Nous développons sous Windows, MacOS ou Ubuntu pour déployer sur RHEL, AIX ou Solaris. Beaucoup d'équipes qui déploient en production sur un 'gros serveur' J2EE poussent même souvent plus loin cette portabilité en préférant utiliser pour le développement un serveur léger : Tomcat ou Jetty. Pour ce qui est des problèmes de voisinage liés au port d'écoute ou aux répertoires utilisés, le monde Java, particulièrement sous Tomcat, a déjà banalisé ce partage en démarrant une instance de serveur par application web. De ce fait, il est fréquent de voir sur de simples serveurs bi-processeurs plus de quatre instances Tomcat démarrées. Grâce à la faible adhérence d'une application Java à son environnement d'exécution et à l'habitude d'installer plusieurs serveurs « à la Tomcat », le niveau naturel de mutualisation des ressources CPU et RAM pour des applications Java est au dessus du système d’exploitation. La complexité et les coûts de la virtualisation matérielle sont très rarement justifiés avec Java. Une simple batterie de serveur Linux avec des serveurs Java ‘légers’ comme Tomcat, Jetty ou Glassfish V3 répond au besoin d’optimisation des data centers Java en conciliant simplicité et faible coût.

Adaptation CPU et RAM en Java : Le modèle ‘scale out’

A la différence du modèle ‘scale-up’ de la virtualisation matérielle qui augmente la CPU et la RAM d’une instance pour tenir la charge, Java utilise un modèle ‘scale-out’ qui consiste à augmenter le nombre d’instances de l’application. Pour garantir la haute disponibilité ou la tenue à la charge, nous déployons des clusters de 2, plutôt 3, voire plus, instances de nos applications Java.
Déployer un nouveau nœud se fait aujourd’hui en moins d’une heure pour une équipe entrainée et ce délai va sensiblement diminuer. La roadmap de SpringSource Tc Server permettra d’adapter les ressources CPU et RAM d’une application Java en moins de 5 minutes d’ici deux ans au plus par simple démarrage ou arrêt de nœuds d’un cluster.
Les tâches à accomplir sont limitées pour SpringSource, IBM le propose depuis des années sur son sophistiqués mais complexe WebSphere eXtended Deployment et Gigaspace vient de l’introduire sur sa grille XAP sur un socle Jetty, SpringSource doit principalement ajouter un mécanisme de déploiement de Tomcat à l’agent Hyperic/AMS et améliorer le scripting de la gestion de configuration Tomcat du serveur d’administration Hyperic/AMS.

Virtualisation matériel : Un marché plus concurrentiel et moins lucratif

En plus d’être remise en cause par la rupture technologique du cloud computing, la virtualisation matérielle est aujourd’hui confrontée à une baisse des marges. VMWare a connu des années très lucratives pendant lesquelles elle a été pionnière ‘pure player’. Certains disaient que « VMWare a porté sur architecture x86 la virtualisation des mainframes ».
Le marché de la virtualisation est aujourd’hui mature, les grands acteurs des systèmes d’exploitation se jettent dans la bataille et la concurrence s’annonce rude pour VMWare.
L’univers Windows est condamné à rétrécir mécaniquement pour VMWare avec l’arrivée en force de Microsoft. Les perspectives sont toutes aussi dures dans le monde Linux avec la montée en puissance des offres de RedHat ou de Sun. Nous avons vu par le passé que toutes les fonctionnalités clefs des gros Unix sont arrivées dans Linux ; les zones Solaris et les partitions AIX sont aujourd’hui banalisées, il n’y a pas de raison que ces technologies n’arrivent pas dans le système d’exploitation au pingouin.

One size does not fit all : Concilier virtualisation matérielle et cloud pour optimiser l’utilisation des data centers

A l’époque où les applications n’étaient pas friendly à la mutualisation, la virtualisation était la technologie de prédilection pour optimiser l’utilisation des ressources des data centers. Aujourd’hui, les applications java légères déployées sous forme de cloud Platform As A Service sont très friendly à la mutualisation et se passent de la virtualisation matérielle. VMWare a suivi cette redistribution des cartes en achetant la solution de cloud computing Hyperic-TcServer-Tomcat de SpringSource.
La virtualisation matérielle risque de ne pas être utilisée sur les applications légères (Java, .Net, PHP, etc) qui représentent aujourd’hui la tendance dominante mais garde sa position de leader pour optimiser l’utilisation des ressources CPU et RAM des autres types d’applications.

Ressources

Publié par

Publié par Cyrille Le Clerc

CTO de Xebia, Cyrille est aussi committer sur le projet Apache CXF. Après être récemment intervenu sur les sites web et les plateformes de web service à fort traffic d'opérateurs de télécommunication, Cyrille est actuellement responsable de la mise en place d'une grille de données inter-continentale pour une grande institution financière française. Après 7 ans chez IBM Global Services et 5 ans chez Xebia, Cyrille a une expérience variée allant du monde commercial aux écosystèmes Open Source dans des approches aussi bien très cadrées et contractuelles que légères et agiles. Cyrille est aussi blogger sur blog.xebia.fr et speaker dans des conférences (In Memory Data Grids & NoSQL, applications prêtes pour la production, etc).

Commentaire

2 réponses pour " Pourquoi VMWare / SpringSource ? Virtualisation matérielle vs. Cloud "

  1. Publié par , Il y a 10 années

    Pour donner corps à la stratégie de virtualisation, il manque vraiment un OS et une JVM (et je ne parle pas de SGBD)… Sinon, tu le dis, eXtended Deployment le fait déjà et n’a pas changé la face de la virtualisation Java ;)

    Donc Spring n’est pas la raison du rachat. Hyperic et Tomcat bien plus, on est d’accord. D’ailleurs Java EE 6 sort en fin d’année avec le JSR 330. Il est voté par vmware/springsource (et tous les autres) qui le recommende puisque Spring n’est plus un enjeu! J’ai tout bon? :)

    PS: JMS = léger? :)

  2. Publié par , Il y a 10 années

    Cher Axel R,

    Je me suis comme vous posé la question de l’absence d’un système d’exploitation (i.e. d’une distribution Linux) et d’une JVM dans la stack VMWare-SpringSource.
    Cependant, en regardant l’histoire des serveurs J2EE, je ne suis pas sûr que ce soit pénalisant.
    Apache Tomcat, IBM WebSphere, Oracle/BEA Weblogic et Sun Glassfish composent très bien avec RHEL qui est pourtant gouverné par RedHat/JBoss.
    De même, Apache Tomcat, Oracle/BEA Weblogic et RedHat/JBoss App Server sont très souvent utilisés sur la JVM de Sun.
    La maturité et la qualité de Linux et de la JVM de Sun font qu’il est facile de les intégrer sans pour autant les maîtriser.

    Pour WebSphere eXtended Deployment (XD), je vous sens taquin ;-) . XD fait partie des nombreuses innovations d’IBM qui sont popularisées par d’autres. La vision du déploiement d’application Java qu’Adrian Coyler a fait lors du dernier SpringOne ressemblait à s’y méprendre à la liste des fonctionnalités d’XD qui a pourtant plus de 5 ans.

    Pour la JSR 330 @Inject et Java EE 6, croyez-vous qu’@Inject unifiera les mécanismes d’injection de dépendance de Servlet 3, JSF, EJB Light , EJB et JCDI/WebBeans ? ;-)

    Quant à JMS, si vous avez eu des expériences heavyweight, je vous recommande vivement d’essayer le trio Tomcat/Spring JMS/ActiveMQ avec lequel j’ai eu des expériences très lightweight ;-).

    A très bientôt j’espère,

    Cyrille, Xebia

Laisser un commentaire

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

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.