PaaS : VMware change-t-il son fusil d’épaule ?

Tanzu Application Platform, une PaaS « modulable » basée sur Kubernetes

Pour rappel, l’éditeur maintient également sa propre distribution de l’orchestrateur, Tanzu Kubernetes Grid, mais il a décidé de ne pas l’imposer aux clients. La plateforme TAP pourra aussi être déployée sur « toutes les distributions Kubernetes approuvées par la CNCF », dont celles proposées par Google Cloud, AWS et Microsoft Azure, promet le responsable.

En outre, la technologie Knative interprétera les runtimes des applications. Knative rassemble des composants middleware capable d’administrer le back-end des containers dans une approche serverless. « Knative va permettre d’exécuter autant des applications Web que des workload batchs ou de streaming », assure Erwan Bornier. En clair, TAP reprend les capacités de Cloud Native Runtime, un produit standalone en bêta depuis juillet reposant sur le même projet open source.

Ensuite, TAP s’appuie sur Spring Initializr, la technologie qui anime Tanzu App Accelerator. Il s’agit d’une bibliothèque d’accélérateurs, des templates pour commencer à bâtir des applications ou des composants. App Accelerator comprend une UI Web permettant chercher des accélérateurs liés à des ressources contenues dans un dépôt Git. Un manifeste yaml définit un descriptif de l’accélérateur et des ressources qu’il appelle dans Git.

Depuis l’interface, les usagers peuvent sélectionner les options pour générer un projet précâblé par d’autres développeurs, par exemple une API écrit en Go. Le template peut ensuite être copié dans un IDE. « Nous investissons pour proposer des plug-ins dans Visual Code pour interagir avec Tanzu », indique Erwan Bornier. Le module Application Live View (basé sur les projets open source Spring Boot Actuator et Observer), lui aussi en bêta, rendra possible la supervision de quelques métriques techniques (consommation de ressources CPU et RAM) et logiques métiers en cours de développement.

Malgré le fait que ces technologies sont intrinsèquement liées au framework Spring Boot, VMware assure que l’offre TAP est autant destinée au développement d’applications Java que celles écrites en Go, JavaScript, Python et .NET.

Une fois l’application écrite et testée, le CLI Tanzu permettra de la déployer sur un cluster Kubernetes. Dans un premier temps, la chaîne CI/CD associée à TAP est composée « d’étapes préétablies », par exemple l’extraction du code depuis un dépôt Git, transmis à Tanzu Build Service, un produit de génération d’images de conteneur en partie basé sur kpack et des pipelines reposant sur Tekton pour étendre l’application sur Kubernetes Grid.

À la commercialisation de Tanzu Application Platform, cette chaîne logistique sera modulable. VMware laissera ses clients sélectionner certains outils de leur choix. La compatibilité avec Jenkins est d’ores et déjà promise, mais l’éditeur ne liste pas encore les autres services cloud compatibles. « Tout comme avec Tanzu Build Service, nous avons la vocation à ouvrir [TAP] à énormément de partenaires », déclare Erwan Bornier.

Enfin, TAS disposera d’un portail pour documenter, retrouver et administrer les API utilisées avec les applications et la PaaS.

Cloud Foundry, vestige du passé ?

Or, depuis 2009, VMware porte le projet Cloud Foundry pour bâtir une telle plateforme reposant, elle sur des machines virtuelles.

Désormais, l’offre PaaS Cloud Foundry se nomme Tanzu Application Service (TAS). Elle est toujours exploitée par les clients de l’entreprise. Interrogé sur la manière de différencier ces deux offres, Erwan Bornier a du mal à ne pas évoquer Cloud Foundry au passé.

« Cloud Foundry était un projet [sic] qui a d’abord été incubé en 2009 par VMware, puis rendu à la communauté après la création de Pivotal en 2013 », rappelle-t-il.

Pivotal a justement été pensé comme un spin-off de VMware consacré à la fourniture d’offres PaaS basées sur Cloud Foundry. Après l’acquisition de Pivotal par VMware en 2019, Pivotal Cloud Foundry est devenu Tanzu Application Service.

« Le sujet n’était pas encore la conteneurisation, mais nous voulions déjà accélérer la capacité des développeurs à pousser du code en production. L’objectif n’a pas tant changé que ça, ce sont plutôt les écosystèmes et les technologies sur lesquels l’on s’appuie qui ont évolué », justifie Erwan Bornier.

Entretemps, Kubernetes a fait son apparition. En sept ans, la technologie d’orchestration de conteneurs a tout emporté sur son passage. « Nous avons vu les deux mouvements se construire en parallèle. Une plateforme avec énormément d’opinions – Cloud Foundry qui a donné Tanzu Application Service – et une plateforme plus complexe, mais beaucoup plus modulable, Kubernetes », résume le responsable.

« Nous avons vu les deux mouvements se construire en parallèle. Une plateforme avec énormément d’opinions , Cloud Foundry [...] et une plateforme plus complexe, mais beaucoup plus modulable, Kubernetes ».

« Parfois un peu tristement le marché et les clients sont un peu technophiles et perdent de vue le gain véritable, à savoir une plateforme abstraite de l’infrastructure sous-jacente pour offrir un service aux développeurs. Le marché a tellement convergé sur Kubernetes qu’à un moment donné VMware Tanzu doit apporter plus d’interactions entre ces deux sujets [Kubernetes et une PaaS] ». Ce serait le rôle de Tanzu Application Platform.

Ce que ne dit pas Erwan Bornier, c’est que les membres de la Fondation Cloud Foundry ont eu beaucoup de mal à s’entendre sur l’interaction entre Kubernetes et CF. D’ailleurs, le débat n’est pas clos malgré une décision officielle annoncée en juillet dernier désignant le projet cf-for-k8s comme l’instrument de cette intégration. En outre, Tanzu Application Service for Kubenetes, basé sur cf-for-k8s, est toujours en développement dans une phase de bêta privée.  

Avec Tanzu Application Platform, VMware semble concentrer ses efforts sur Kubernetes, mais il n’a pas mis publiquement fin à TAS for Kubernetes.

Interrogé sur cette possible annulation par SearchITOperation [propriété de TechTarget, également propriétaire du MagIT], Gary Chen, analyste chez IDC, estime que l’approche de l’éditeur ne porte pas forcément préjudice aux utilisateurs de Cloud Foundry.

« Je ne pense pas que ce serait la fin du monde si Cloud Foundry et Kubernetes restent séparés, avec de nouvelles applications déployées sur Tanzu Application Platform », déclare-t-il. « Le calcul a peut-être changé… La stratégie pourrait consister à ne pas toucher aux systèmes existants ».

MAJ : En commentaire de cet article, Erwan Bornier n’a pas une réponse définitive quant à la disponibilité de Tanzu Application Service for Kubenetes et son sort. En revanche, il tient à rappeler que le code source de TAS et de Cloud Foundry sont très proche et que VMware demeure le contributeur numéro 1 au projet open source. Quant aux interactions possibles entre Tanzu Application Service et Tanzu Application Platform, l’intéressé ne dit pas si les deux plateformes peuvent communiquer, mais évoquent des bases technologiques communes qui permettraient d’adopter Kubernetes et TAP, si nécessaire.

« Les deux plateformes [TAS et TAP] reposent sur le mécanisme de buildpacks que les développeurs ont l’habitude de manipuler et qui dépend depuis plusieurs années d’un projet CNCF. Cette brique technologique apporte donc de la cohérence et de la standardisation sur la stratégie de conteneurisation des clients », assure-t-il. « Un autre exemple, les modules de monitoring tels que Tanzu Observability peuvent également être utilisés avec les deux plateformes aussi bien pour superviser autant la plateforme que la couche applicative ».

En outre, le responsable assure que VMware ne veut pas forcer ses clients à migrer des applications d’une plateforme à l’autre, tout dépendra de leur choix et de l’intérêt à le faire.

« Nous fournirons les bons outils clés en main si des applications doivent migrer d’un environnement à l’autre, s’il y a une vraie valeur à le faire pour le client ».

Red Hat OpenShift en ligne de mire

En revanche, avec TAP, VMware se retrouve en concurrence directe avec Red Hat OpenShift. « Nous ciblons les mêmes clients et les problématiques à résoudre sont similaires », reconnaît Erwan Bornier. « VMware Tanzu a une crédibilité importante dans le domaine de l’infrastructure, notamment avec vSphere. Nous sommes aussi à l’origine de Spring Boot, très utilisé par les développeurs », vante-t-il.

Red Hat formulerait sans doute une réponse semblable, mais peut déjà se targuer d’avoir la plateforme Kubernetes la plus largement adoptée en dehors du cloud public, avec plus de 3 000 entreprises clientes à ce jour.

De son côté, Gary Chen rappelle que Red Hat OpenShift est forcément attaché à la distribution Red Hat Linux Enterprise (RHEL). « Tanzu Application Platform offre les mêmes possibilités [que Red Hat OpenShift] sans nécessiter une version particulière de Linux », déclare-t-il. « Le fait qu’elle ne soit pas soudée à Tanzu Kubernetes Grid est également la bonne décision ».

Selon les propos d’Erwan Bornier, VMware cherche à convaincre les organisations qui n’ont pas encore déployé Kubernetes en production et celles qui veulent « simplifier » les nouveaux déploiements.

Pour autant, ceux qui ont déjà opté pour la conteneurisation ont souvent composé la supply chain associée.

« Je n’ai pas beaucoup de clients qui dans le cadre de leur utilisation de Kubernetes n’ont pas entrepris de construire quelque chose par-dessus l’orchestrateur pour simplifier l’usage », reconnaît-il.

« Nous pouvons envisager que certaines lignes métiers adoptent Tanzu Application Platform, quand elles n’ont pas le temps de se concentrer sur Kubernetes », ajoute-t-il.

L’offre devra donc trouver sa place sur le marché sans créer de confusion pour les clients qui ont déjà opté des modules Tanzu, les nouveaux venus et ceux en provenance de Cloud Foundry.