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 atouts de la virtualisation matérielle
• Les limitations de la virtualisation matérielle pour Java
• Mutualisation en Java : De simples serveurs Linux-Tomcat suffisent
• Adaptation CPU et RAM en Java : Le modèle ‘scale out’
• Virtualisation matériel : Un marché plus concurrentiel et moins lucratif
• One size does not fit all : Concilier virtualisation matérielle et cloud pour optimiser l’utilisation des data centers

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

• « SpringSource: Chapter Two » : L’annonce du rachat par Rod Johnson, fondateur de SpringSource.
• « VMWare to acquire SpringSource » : L’annonce par Steve Herrod, CTO de VMWare.
• « Why Java is important to VMware but may not matter long term » par Billy Newport, IBM WebSphere.
• « SpringSource racheté par VMware » par Le Touilleur Express.