TAP : VMware mime l’expérience Cloud Foundry sur Kubernetes

Certains utilisateurs des distributions VMware Tanzu de Cloud Foundry prévoient de passer sur Kubernetes avec la plateforme TAP, mais VMware devra prouver sa valeur face à Red Hat, SUSE et d’autres concurrents.

VMware a annoncé la disponibilité générale de Tanzu Application Platform (TAP) cette semaine, avec l’aval de quelques clients Cloud Foundry.

Une première version bêta de TAP a été déployée en septembre 2021, suivie de mises à jour mensuelles qui ont abouti à la bêta 4 en décembre. La bêta 2, lancée en octobre, a jeté les bases des intégrations avec les produits de gestion multicloud de VMware. La bêta 3, en novembre, a ajouté des fonctionnalités telles que les profils de plateforme, qui automatisent l’installation de clusters Kubernetes via des paquets open source créé avec le set d’outils Carvel de VMware.

La version bêta 4, la version candidate maintenant prise en charge en production en tant que mouture 1.0 de TAP, a réduit le temps d’installation des profils de plateforme de plus de sept heures et a introduit une interface utilisateur graphique basée sur Backstage, un projet de création de portails développeurs ouvert par Spotify. VMware a refusé de divulguer le prix de cette Tanzu Application Platform. Elle peut être déployée sur AWS, Azure, GCP ou sur des clusters sur site.

La bêta 4 contenait également ce que les responsables de VMware ont appelé une amélioration critique lors d’un point de presse la semaine dernière. Il s’agit de diviser les portions d’automatisation des tests (CI) et de livraison continue (CD) de la chaîne d’outils DevOps intégrée de TAP, ainsi que des corrections de bugs et des mises à jour de stabilité.

« Nous avons séparé notre logique de chaîne d’approvisionnement des composants qui s’occupent de la livraison de l’application elle-même », indique Valentina Alaria, directrice de la gestion des produits pour les applications cloud-natives chez VMware. « Elle peut être plus facilement mise en correspondance avec un environnement multiclusters, où les [clients] veulent exécuter le cœur de [la] chaîne d’approvisionnement, avec les tests d’intégration et l’analyse sur un cluster, puis cibler un cluster différent en production pour exécuter le workload. »

TAP, un « point de bascule » potentiel pour les utilisateurs de Cloud Foundry

Les utilisateurs de VMware Tanzu Cloud Foundry ont évoqué lors de la conférence de presse de l’éditeur le lancement de PoC sur TAP. Ils poursuivront l’évaluation du produit en vue de son utilisation en production cette année.

Certains clients, membres du groupe de super-utilisateurs VMware Tanzu, appelé Vanguard, avaient précédemment manifesté l’espoir que VMware relance les efforts visant à fusionner les interfaces utilisateur entre son service Tanzu Application Service (TAS) – basé sur Cloud Foundry – et le nouveau TAP – basé sur Kubernetes. Désormais, certains d’entre eux commencent à envisager de migrer vers TAP et de s’éloigner de TAS à long terme.

« TAP offre aux personnes souhaitant développer sur Kubernetes avec la même rapidité que sur Cloud Foundry, ainsi que la possibilité de faire des choses qu’elles ne pouvaient pas faire auparavant », affirme Greg Meyer, ingénieur distingué chez Cerner, une société spécialisée dans la gestion des infrastructures IT médicales rachetée par Oracle et membre de Vanguard. « Cela pourrait très bien finir par être le point de bascule [vers Kubernetes] pour les personnes utilisent actuellement TAS au sein de leurs organisations ».

Ce sera vraisemblablement le point de bascule pour Cerner, du moins, a-t-il ajouté lors d’une interview auprès de SearchITOperations [propriété de TechTarget, également propriétaire du MagIT].

« Kubernetes constitue notre approche à plus long terme », confirme Greg Meyer. « TAP va plus que probablement être la “route pavée” [vers la production] que nous allons créer ». Il y a quelques mois, Greg Meyer s’inquiétait du fait que VMware puisse abandonner progressivement TAS. L’éditeur s’était chargé de le rassurer à ce sujet.

Kubernetes est déjà utilisé au sein de l’entreprise, précise Bryan Kelly, ingénieur logiciel chez Cerner, lors du point de presse. TAP aidera idéalement l’entreprise hautement réglementée à maintenir le contrôle de l’entreprise sur les déploiements de logiciels à des fins de conformité, tout en ajoutant une plus grande flexibilité pour les développeurs en comparaison avec l’approche prescriptive de la plateforme de Cloud Foundry.

« Nous avons des équipes qui manipulent Helm, nous avons des équipes qui utilisent Spinnaker, Argo CD, Flux CD, Tekton – vous pourriez lancer une fléchette dans le paysage cloud-native et trouver une équipe qui a essayé ou utilise actuellement la cible atteinte », déclare Bryan Kelly. « Cela ne réussit pas à une entreprise de gérer ces développements et ces opérations en production de cette manière, car cela nuit à la portabilité des développeurs entre [équipes] ou à l’aide aux initiatives d’autres [équipes]. »

En la matière, TAP doit reproduire le caractère dirigiste de Cloud Foundry et l’appliquer dans des environnements Kubernetes. VMware a établi une supply chain composée d’environnements GIT (GitHub, GitLab ou Azure DevOps). Le code poussé est « synchronisé » avec Kubernetes à l’aide de Flux, Tekton propulse la partie CI, les Cloud Native Buildpacks sont utilisés pour automatiser la génération des images de conteneur. Pour analyser les images, TAP intègre Grype, un scanner de vulnérabilités issu d’un projet open source (sous licence Apache 2.0) mis au point par Anchore.

Les conventions Vmware, basées sur Spring Boot permettent aux développeurs et surtout aux Ops de configurer la manière dont un workload doit s’exécuter (par exemple, il est possible de définir à quel moment un Pod doit s’éteindre). Knative est ensuite utilisé pour déployer les charges de travail sur un cluster Kubernetes. Comme promis, VMware a développé une extension TAP pour VScode.

L’attrait de TAP en dehors de l’écosystème Tanzu demeure une question ouverte

VMware dispose sans doute d’un public captif parmi ses clients TAS, qui ont besoin d’aide pour passer de la PaaS à une infrastructure DevOps plus moderne basée sur Kubernetes, et qui ont déjà une relation avec le support technique de VMware. Au cours du point de presse, les membres du groupe d’utilisateurs Tanzu Vanguard ont également déclaré qu’une plateforme d’apprentissage intégrée ajoutée à TAP dans la version bêta 3 sera cruciale pour la formation du personnel des opérations IT.

Cette fonctionnalité, appelée Centre d’apprentissage, propose des démonstrations pratiques basées sur la plateforme de leur entreprise que les développeurs et les professionnels des opérations IT peuvent parcourir plutôt que des instructions génériques qu’ils doivent traduire en fonction des activités de leur entreprise.

« Le Centre d’apprentissage m’a enthousiasmé lorsque j’en ai vu les images », affirme Raji Padmanaban, directeur informatique de OneMagnify, une société de marketing et de publicité qui utilise depuis longtemps la plateforme Pivotal Cloud Foundry. Toutefois, les représentants de OneMagnify qui se sont exprimés lors de la réunion d’information n’ont pas précisé si la société s’était déjà engagée à mettre TAP en production.

En dehors de la base d’utilisateurs de TAS, des concurrents tels que IBM Red Hat, SUSE Rancher et des fournisseurs cloud tels que AWS offrent depuis des années une expérience Kubernetes aux entreprises, et il pourrait être difficile pour VMware Tanzu de rattraper son retard.

Les responsables de VMware vantent les chaînes d’approvisionnement DevSecOps préconstruites comme la principale différenciation de TAP, qui peut également être personnalisée par les ingénieurs de la plateforme pour s’adapter aux préférences des développeurs.

Pour cela, VMware a créé un « chorégraphe de supply chain » open source pour Kubernetes nommé Cartographer. « Cartographer fournit un ensemble de contrôleurs Kubernetes et de CRDs (Custom Ressource Definitions) qui permettent à un opérateur de créer une plateforme applicative en spécifiant des plans (BluePrints ou templates) définissant des parcours de déploiements du code en production répétables et réutilisables », peut-on lire dans la documentation.

« Lorsque nous effectuerons notre migration vers TAP, nous devrons repenser notre supply chain, mais je pense qu’il y a de bonnes raisons de le faire et nous obtiendrons beaucoup plus de valeur avec quelque chose sur étagère ».
Brian KellyIngénieur logiciel, Cerner

Cartographer a été pensé avec Tekton en tête, mais l’éditeur précise qu’il est compatible avec Jenkins, ou d’autres outils existant d’une chaîne CI/CD, tant qu’ils peuvent manipuler des objets Kubernetes. Mieux, il serait possible d’interchanger les outils (par exemple, une équipe A utilise Tekton, mais Kaniko au lieu de Knative, tandis que l’équipe B préfère Jenkins et Knative) sans que la chorégraphie de la supply chain (les étapes configurées dans les templates Cartographer) en soit perturbée.

« Pour moi, c’est la partie la plus intéressante de TAP », assure Bryan Kelly. « La plateforme Cloud Foundry est très opinionée, mais nous avons tout de même dû bâtir notre propre chaîne d’approvisionnement. Lorsque nous effectuerons notre migration vers TAP, nous devrons repenser notre supply chain, mais je pense qu’il y a de bonnes raisons de le faire et nous obtiendrons beaucoup plus de valeur avec quelque chose sur étagère », poursuit-il.

Pour ce qui est de l’approche DevSecOps, en sus des scans des images, VMware assure que les Cloud Native Buildpacks permettent de se départir de certaines vulnérabilités, dont celle touchant Log4j, en s’appuyant sur le SBOM (Software Bill of Material) généré par les buildpacks de Paketo.

De plus, le chorégraphe de supply chain doit permettre de « prévalider » les étapes de test, de build, de scan et de déploiement tout en garantissant l’indépendance et donc l’isolement de chacune de ces phases.

Mais il n’est pas certain que cela trouve un écho auprès des équipes Agile et DevOps. Selon un analyste, certains pourraient craindre de revenir aux temps troublés des processus de contrôle du changement des méthodes ITIL et Waterfall.

« La normalisation de toutes les chaînes d’outils, de toutes les dépendances et de ce genre de choses m’amène à me demander si les opérateurs doivent désormais savoir ce dont les développeurs ont besoin avant qu’ils n’en aient besoin ».
Rob Strechayanalyste, ESG

« La normalisation de toutes les chaînes d’outils, de toutes les dépendances et de ce genre de choses m’amène à me demander si les opérateurs doivent désormais savoir ce dont les développeurs ont besoin avant qu’ils n’en aient besoin, et s’ils doivent mettre en place un modèle », avance Rob Strechay, analyste chez Enterprise Strategy Group, une division de TechTarget. « Cela va un peu à l’encontre de l’évolution du développement au cours des dernières années ».

Néanmoins, l’incorporation du projet Backstage, en plein essor, dans TAP pourrait renforcer la popularité de VMware Tanzu, nuance-t-il.

« C’est un nouveau nom qui apparaît [parmi] certaines personnes qui pensent que Rancher n’est pas aussi agnostique [aux différentes distributions Linux sous SUSE] qu’il l’était auparavant », déclare-t-il. « Mais Backstage a beaucoup de modèles et de connecteurs, beaucoup de choses identiques [à TAP] – c’est quelque chose que je veux creuser un peu et voir à quel point VMware contribue réellement en retour. »

Pour approfondir sur PaaS

Close