Le numéro 2 des distributions Linux, désormais autonome, mise sur du Cloud SAP Hana de 60 To ou du Cloud Foundry en seulement trois containers pour se démarquer de Red Hat.
Face au rouleau-compresseur Red Hat et ses résultats trimestriels à plus de 800 millions de dollars, le challenger Suse – qui espère atteindre un CA de 400 M$ en 2019 – joue la carte des solutions originales. Tenant son salon annuel à Nashville, dans le Tennessee, l’éditeur européen de Linux a dévoilé deux produits qui défient le sens commun : des instances Azure pour SAP Hana qui supportent jusqu’à 60 To de RAM et une plateforme Cloud Foundry qui fonctionne... sans Cloud Foundry.
« Nous voulons proposer à nos clients les technologies qui les aideront à gérer les exigences les plus subtiles de leur transformation digitale, pour qu’ils puissent prendre une longueur d’avance auprès de leurs clients et sur leurs marchés respectifs », a déclaré sur scène Nils Brauckmann, le PDG de Suse.
Après une série de changements de propriétaires depuis 2003 (Novell, Attachmate, Micro Focus), l’éditeur a finalement été revendu pour un peu plus de 2,5 Md$ à une filiale allemande du fond d’investissement EQT Partners, le 25 mars dernier. Et selon Nils Brauckmann, ce rachat, en projet depuis juillet 2018, aurait redonné à son entreprise toute la latitude pour investir en R&D. Il cite en particulier l’embauche ces derniers mois de 300 ingénieurs – soit une augmentation de 20 % de son personnel rien que pour l’innovation.
Simplifier le modèle Cloud Foundry à l’extrême
La nouvelle version 1.4 de Cloud Application Platform (CAP), l’implémentation du PaaS Cloud Foundry pour les DevOps par Suse, présente donc l’originalité d’être réduite au strict minimum : juste trois containers Docker contenant des bibliothèques de développement, le module Eirini qui dialogue avec Kubernetes et la console d’administration simplifiée Stratos.
« Habituellement, une distribution Cloud Foundry est monolithique. Déjà, techniquement, elle s’appuie sur une vingtaine de machines virtuelles que l’utilisateur doit déployer et administrer lui-même. Non seulement c’est de l’infrastructure informatique bien trop compliquée pour les utilisateurs finaux de Cloud Foundry – les développeurs – mais c’est aussi très cher en ressources, qu’il s’agisse de serveurs physiques à acheter ou de VM à louer en cloud », explique au MagIT Thomas Di Giacomo, le CTO de Suse.
« Une telle distribution [Cloud Foundry] n’est pas optimale, car elle encapsule Kubernetes dans des couches qui n’ont plus lieu d’être. »
Thomas Di GiacomoCTO, Suse
« Ensuite, une telle distribution n’est pas optimale, car elle encapsule Kubernetes dans des couches qui n’ont plus lieu d’être », poursuit-il. Il rappelle que Cloud Foundry, qui a été créé bien avant l’arrivée de Kubernetes, a conservé son architecture d’origine en machines virtuelles, puis a cédé à la mode des containers en lui ajoutant des ordonnanceurs primitifs comme Diego ou Bosh, puis exécute par-dessus ceux-ci l’ordonnanceur Kubernetes pour être compatible avec les technologies modernes.
L’enjeu de remplacer Pivotal
« En ce qui nous concerne, nous livrons une implémentation qui se résume aux seules fonctions propres à Cloud Foundry et qui est à installer par-dessus une infrastructure Kubernetes déjà existante. Nous ne sommes pas là pour avoir la prétention de fournir le moteur, nous sommes là pour répondre au besoin de la manière la plus optimale et la moins chère possible », conclut-il, en assurant que CAP 1.4 fonctionne aussi bien par-dessus n’importe quelle distribution Kubernetes sur site, qu’en hébergement sur les services cloud équivalents chez Azure (AKS), AWS (EKS), Google (GKE), ou autre.
« La solution de Suse repose sur le projet Eirini, un module co-développé avec IBM et SAP pour greffer l’environnement fonctionnel de Cloud Foundry à Kubernetes. Et nous constatons qu’il y a un vrai espoir de la part des entreprises que le trio Suse-IBM-SAP parvienne à renverser Pivotal, l’actuel leader des implémentations commerciales, avec ses factures à rallonge », témoigne un partenaire de Suse qui ne souhaite pas que son nom soit cité.
Selon un rapide sondage mené par le MagIT au cours du salon, il apparaîtrait que l’autre attrait de CAP serait son interface d’administration Web Stratos. Sa faculté à monitorer à la fois le fonctionnement des applications écrites par les développeurs et celui de toutes les infrastructures Kubernetes qui les motorisent sur site comme en cloud a été citée à plusieurs reprises comme l’un des exemples à suivre en matière de pilotage de cloud hybride.
Des instances Hana de 60 To en cloud
L’annonce des instances de Linux dédiées à SAP Hana, et qui parviennent à offrir jusqu’à 60 To de RAM lorsqu’elles sont hébergées dans le cloud Azure, va de pair avec le support tout récent des derniers processeurs Xeon d’Intel dans le noyau mis au point par Suse. La caractéristique ici exploitée est manifestement l’utilisation par ces Xeon de nouvelles barrettes mémoire Optane DC Persistent Memory deux fois plus capacitives. Ce serait l’un des secrets de cette offre exclusive à Azure, le cloud public de Microsoft.
« Microsoft a redoublé d’efforts pour concrétiser cette offre parce que Hana ne fonctionne que sur Linux, ce qui signifie qu’il perd régulièrement des clients qui veulent moderniser leurs applications SAP Windows », confie au MagIT Ronald Nunan, le maître d’œuvre de ces instances gigantesques chez Suse.
« Je témoigne que la mise au point de cette offre a été particulièrement compliquée et, pour finir, les serveurs utilisés ne font pas partie du pool de ressources habituelles d’Azure. D’ailleurs, les instances de SLES (la distribution Linux de Suse, ndr) ne fonctionnent pas ici en machines virtuelles, chacune d’elle est exécutée en bare metal, sur un serveur physique dédié. »
95 % des bases Hana déjà transposables en cloud public
Selon divers partenaires de Suse, la cible privilégiée de ces instances gigantesques ne serait pas tant les clients actuels de SAP Hana, mais plutôt les entreprises qui cherchent une solution simple pour passer leurs bases Oracle de 10 ou 20 To à un mode In-Memory dix fois plus rapide.
« Sur ces trois dernières années, je n’ai rencontré que deux fois des clients avec une base Hana de plus de 5 To », lance par exemple Christian Wissmann, le vice-président de Protera, un prestataire spécialisé dans la migration des solutions SAP en cloud.
Il explique : « 95 % des déploiements transactionnels - c’est-à-dire la partie ERP, soit tout ce qui concerne la facturation et qui fonctionne sur Hana - fonctionne sur les machines virtuelles que tous les cloud publics proposent actuellement. Lorsqu’une base de données commence à atteindre 10, 20 ou 30 To, c’est sur la partie Business-Warehouse, où l’on cumule des données historiques pour les analyser. Et, dans ce cas, ce n’est plus du Hana, c’est-à-dire que nous pouvons découper la base pour fonctionner sur plusieurs nœuds en parallèle, chacun avec une quantité de mémoire raisonnable. »
Les utilisateurs de grandes bases SQL sont les véritables cibles
« Le cas d’Oracle ou de tout autre serveur SQL est différent. Dans ce cas, les entreprises se retrouvent effectivement avec des bases transactionnelles de plus de 10 To et elles vont naturellement chercher des offres cloud capables d’héberger une telle quantité d’informations, ce à quoi répond cette offre conjointe de Suse et Azure. », poursuit-il.
« Cependant, c’est un faux problème : en effet, si ces bases pèsent autant, c’est uniquement parce qu’elles cumulent quatre, cinq années ou plus d’index. Or, non seulement 50 % de ces To sont constitués d’index qui pointent vers des données entretemps effacées, mais, de surcroit, les index ne servent qu’à pallier la lenteur des disques. Ils sont inutiles avec une base In-Memory. Si bien que la taille de votre base SQL sera réduite de plus de la moitié dès lors que vous la migrerez sur Hana et elle pourra alors être hébergée sur n’importe quel cloud public », démontre Christian Wissmann.
Néanmoins, il ne considère pas l’offre de Suse et AWS comme un coup d’épée dans l’eau. « L’innovation technologique appelle à l’innovation des processus. À mon avis, le modèle des instances gigantesques d’Hana sur Azure sera sans doute celui de la virtualisation des bases de données : d’ici à quelques mois, je pense que nous serons plusieurs à souscrire à ces solutions pour mettre, par exemple, six silos de six clients différents dans une seule base », conclut-il.
