A l’occasion de son récent Red Hat Summit, l’éditeur phare de Linux a insisté sur sa faculté à réduire les risques d’erreurs humaines dans les grands groupes grâce aux containers.
Red hat n’a certainement pas eu le même succès que VMware dans la virtualisation des serveurs, mais il pourrait bien se rattraper avec les containers. C’est ce que prédisait l’année dernière le Magic Quadrant de Gartner et c’est ce que l’éditeur vient de tâcher de démontrer lors de son salon annuel Red Hat Summit qui se tenait début mai à Boston.
« Nous avons permis aux entreprises de mettre en production plus de containers que n’importe lequel des autres fournisseurs d’infrastructure. Cisco, Disney, Volvo, BMW ou encore Deutsche Bank figurent parmi nos clients », a déclaré Paul Cormier, le vice-président de Red Hat en charge des produits et des technologies, lors de l’événement.
LeMagIT y a pour sa part rencontré Airbus, LaPoste et Amadeus. Tous trois nous ont expliqué avoir déployé des containers grâce aux solutions de Red Hat afin d’industrialiser le déploiement de leurs applications de manière plus efficace qu’ils ne le faisaient avec VMware seul.
OCP 3.5 pour des applications traditionnelles en containers plutôt qu’en VM
La solution de Red Hat pour mettre des applications en containers s’appelle OpenShift Container Platform (OCP). Le salon mettait en exergue les bénéfices de sa toute dernière version 3.5, qui offre aux applications les mêmes fonctions d’infrastructure que les VM (en particulier l’accès vers le stockage via le SDS Red Hat Gluster, la sauvegarde des changements d’état, etc.). Cette mouture 3.5 présente l’avantage d’exécuter aussi les applications traditionnelles, à présent appelées « monolithiques » (par opposition aux seuls « microservices » que les containers servaient jusqu’ici à exécuter). On parle ici des bonnes vieilles applications métiers, écrites en Java, avec une base de données SQL et qui sont habituellement mises en production via des machines virtuelles.
Comparativement, pour exécuter 10 applications Java différentes, il faut déployer 10 machines virtuelles, chacune avec son propre OS et ses propres couches de services applicatifs - ou une seule fois l’OS et les services applicatifs sur un serveur avec dix containers qui ne contiennent chacun que leur application.
L’avantage de la seconde option est qu’elle consomme moins de ressources (CPU, RAM, etc.) et que l’on peut mettre à jour l’OS, ou un composant système, sans avoir besoin de réinstaller l’application à chaque fois.
Toutes les entreprises que nous avons rencontrées cumulent les deux solutions : le cluster de containers et sa couche OpenShift sont installés dans une machine virtuelle, laquelle est tantôt exécutée en local par VMware, tantôt sur un cloud privé OpenStack, tantôt chez Amazon AWS, Google Engine ou Microsoft Azure.
« Notre but n’est pas de prendre des parts de marché à VMware, juste d’offrir une pile plus légère et plus simple par-dessus n’importe quelle infrastructure en place », assure Hervé Lemaître, le CTO français de Red Hat.
Déployer de manière automatisée, sans risque d’erreur
L’autre avantage d’OCP 3.5 est qu’il construit de manière automatique les clusters de containers par-dessus sa propre pile système (composée du Linux Red Hat RHEL, du moteur Docker, de l’orchestrateur Kubernetes, du serveur applicatif Red Hat Jboss...) et adapte à la volée cette dernière à l’infrastructure sous-jacente. Les entreprises n’ont dès lors plus qu’à provisionner des VM OpenShift - là sur VMware, là en Cloud privé ou public - pour multiplier rapidement et facilement les instances de leurs applications selon leurs pics d’activité, leurs besoins géographiques ou leurs contraintes réglementaires.
A l’inverse, quand on part d’une application directement installée en machine virtuelle, la déployer sur une autre infrastructure n’est ni facile ni rapide. Cela demande de réinstaller entièrement l’application et sa couche système dans une nouvelle VM, puis de tester à chaque fois ses performances et sa compatibilité. Ces manipulations prennent du temps et présentent le risque d’introduire des erreurs.
A l’occasion de son salon, Red Hat a par ailleurs annoncé l’amélioration des accessoires qui servent à administrer les clusters de containers. Health Index est un nouveau portail qui liste les composants à mettre à jour.
Plus important, l’outil de configuration automatique Ansible - racheté par Red Hat il y a un an - est intégré à la nouvelle version 4.5 de l’outil maison de déploiement automatique, Cloudforms. Ansible dispose d’un millier de jeux de règles (des « playbooks ») pour configurer automatiquement réseau, stockage, sécurité, bases de données et autres OS nécessaires à tel ou tel type de containers. Cloudforms 4.5, quant à lui pilote le déploiement automatique des containers selon les règles d’Ansible en dialoguant avec les modules vApp de VMware, Heat d’OpenStack, CloudFormation d’AWS, ou encore Azure Stack de Microsoft.
Déployer une application n’est qu’exécuter des commandes à la chaîne. Le faire de manière automatique grâce à Ansible évite aux humains de commettre des erreurs. C’est critique pour Airbus.
Nicolas Fanjeau, Airbus
« Déployer une application n’est finalement qu’exécuter des commandes à la chaîne. Le faire de manière automatique grâce à Ansible évite aux humains de commettre des erreurs. C’est critique pour Airbus, car une erreur à ce stade pourrait retarder la commande d’une pièce. Ce qui retarderait une chaîne de fabrication, ce qui bloquerait une usine pendant plusieurs heures. Ce qui au final, revient à des millions d’euros perdus », commente Nicolas Fanjeau, en charge des outils ITSM à la DSI d’Airbus.
Où va Red Hat ?
Restent deux lancements faits lors de ce salon qui posent question.
Tout d’abord, si Red Hat se targue de déployer des clusters de containers universels, qui fonctionnent partout, l’éditeur a tout de même dévoilé une alliance avec Amazon pour utiliser depuis OCP des services propres à AWS (base de données RedShift, répartiteur de charge Elastic Load Balancer, stockage S3 via Gluster, etc.). Sauf qu’un tel cluster de containers ne pourra dès lors plus fonctionner ailleurs que sur AWS.
« Il y a une certaine appétence de la part des entreprises à choisir des services natifs à AWS. Mais nous ne sommes pas là pour choisir des prestataires à la place de nos clients. Nous voulons juste montrer qu’un écosystème se construit autour d’OpenShift. Vous verrez des partenariats similaires avec d’autres clouds publics prochainement », s’est défendu Paul Cormier.
Le second lancement est OpenShift.io. Il s’agit d’un environnement de mise en production d’applications, qui fonctionne en SaaS, et dont les fonctions commencent en amont d’OCP. En effet, il intègre un environnement de développement complet, IDE compris, qui permet aux développeurs de programmer leurs applications directement dans la plateforme. Le détail le plus plébiscité est qu’OpenShift.io est... gratuit.
Gratuit. Vraiment ?
« Le problème d’OpenShift est que les entreprises ne peuvent pas le tester sans au préalable l’intégrer à leur chaîne de production, ce qui est compliqué. L’intérêt d’OpenShift.io est que tout est intégré ; il suffit donc de s’en servir pour écrire du code afin de pouvoir tester l’enchaînement de mise en production que nous proposons. Mais nous sommes bien dans le cadre d’un produit de démonstration, avec des applications mises en production dans le cloud de Red Hat. A terme, nous vendrons peut-être une version on premise d’OpenShift.io », a bien voulu sous-titrer Hervé Lemaître.
Echec des micro-services ?
Enfin, on pourrait aussi se demander si le fait d’exécuter des applications monolithiques dans des containers ne signe finalement pas l’échec des microservices. Ce sont les fragments de code que les containers étaient juste censés exécuter au départ, au prétexte que ce serait bien plus simple pour faire les mises à jour d’une application fonction par fonction, sans devoir redéployer l’intégralité du code à chaque fois.
« Beaucoup de nos clients n’étaient pas prêts pour ré-architecturer leurs applications sous la forme de microservices. Cela dépasse la question technique. Il faut aussi travailler sur la réorganisation des équipes, ce qui n’est pas simple. Avec OCP 3.5 qui exécute les applications traditionnelles en containers comme si elles tournaient en machines virtuelles, nous faisons sauter cette barrière et nous donnons ainsi aux entreprises une solution plus légère et plus moderne que la pile de virtualisation classique pour produire des applications qui s’exécutent dans le cloud », conclut Hervé Lemaître.
Selon leurs déclarations officielles, Red Hat réalise désormais un CA annuel de 2,1 Md$, en progression de 20% d’une année sur l’autre. VMware réalise quant à lui à présent un CA annuel de 7,1 Md$, en progression de 9% depuis l’année dernière.
