Sergey Nivens - Fotolia
Cloud Foundry a deux voies, mais un seul objectif : Kubernetes
Cette semaine se tenait le Cloud Foundry Summit Europe. Outre les mises à jour des composants du PaaS, c’était l’occasion pour les contributeurs principaux de rappeler qu’enfin ils ont trouvé un point d’accord pour intégrer Cloud Foundry à Kubernetes, même si pour l’instant deux voies coexistent.
Après un changement à la tête de la fondation Cloud Foundry en avril, le nouveau président, Chip Childers, a souhaité insuffler une direction claire pour le présent et l’avenir de la PaaS : « Fournir la meilleure expérience de développement possible sur Kubernetes ».
Cette direction n’est pas nouvelle. Il y a deux ans déjà, la fondation voyait poindre deux projets portés par SUSE, IBM et SAP : CF Containerization (devenu cf-operator) et Eirini. CF Containerization était alors un moyen de convertir des manifestes BOSH en Helm Charts pour déployer les containers Cloud Foundry sur Kubernetes.
Pour rappel, BOSH est un composant de gestion et de monitoring des déploiements distribués d’applications multicloud dédié au PaaS. Eirini, lui, est un backend qui permet de déployer directement les applications développées avec Cloud Foundry sur Kubernetes ou sur Diego pour la gestion des containers. Les deux projets portaient la vision d’une intégration native au célèbre orchestrateur.
Seulement, Pivotal, depuis acquis par VMware, n’était pas du même avis. BOSH était alors au cœur d’une offre nommée PKS afin de gérer les clusters Kubernetes. L'éditeur continue de le supporter pour ses clients existants.
Edit : VMware PKS est bien supporté, nous rappelle l'éditeur. Le produit a depuis changé d'appellation et se nomme désormais VMware Tanzu Kubernetes Grid Integrated Edition depuis la version 1.8.
« En deux ans, beaucoup de choses ont changé dans la bonne direction concernant les technologies et l’architecture de Cloud Foundry, mais aussi en termes des priorités et de la vision des entreprises et des membres de la communauté qui y contribuent », affirme Thomas Di Giacomo, président de l’innovation et de l’ingénierie chez SUSE et membre du comité de direction de Cloud Foundry Foundation.
Thomas Di GiacomoPrésident de l’innovation et de l’ingénierie, SUSE
Eirini est désormais prêt pour une utilisation en production, depuis mai 2020. SUSE avait proposé Suse Cloud Foundry, devenu entretemps KubeCF au sein de la fondation. Cette distribution de Cloud Foundry Application Runtime (CFAR) pour Kubernetes est entrée en version 2.5.8 un peu avant l’événement virtuel. « Nous utilisons cette technologie dans nos produits depuis près de trois ans », assure Thomas Di Giacomo. KubeCF utilise cf-operator et Eirini (maintenant tous deux placés sous la direction du projet Quark), entre autres.
Deux nouvelles manières d’envisager le PaaS Cloud Foundry
Mais un autre projet pour déployer Cloud Foundry sur Kubernetes a vu le jour : cf-for-k8s. Ce dernier est passé en version 1.0 cette semaine alors qu’il n’était qu’en 0.1.0 en juillet dernier. La nouvelle mouture devrait être disponible incessamment sous peu depuis la page GitHub dédiée. Cf-for-k8s (Cloud Foundry for Kubernetes) est principalement soutenu par VMware Tanzu (anciennement Pivotal). Le projet est conçu pour supprimer BOSH et pour jouer le rôle d’interface via une API entre CFAR et des composants comme le service mesh Istio, envoy, FluentD, Eirini ou encore Kpack.
« VMware est partie d’une feuille blanche. Cf-for-k8s est plus récent, moins mûr, mais il s’affranchit des contraintes que l’on peut rencontrer avec l’ancien Cloud Foundry. Nous participons à ce projet également, VMware participe un peu à KubeCF, IBM fait un peu des deux », déclare Thomas Di Giacomo.
« Nous aurons de moins en moins besoin de faire la transition du vieux Cloud Foundry vers le nouveau Cloud Foundry et donc ces deux projets sont amenés à converger à l’avenir. Cela peut paraître un peu redondant de l’extérieur, [KubeCF et cf-for-k8s] sont deux projets, mais ce sont deux approches différentes qui vont finir par s’intégrer ensemble. »
Thomas Di GiacomoSUSE
Chip Childers partage cet avis. « [Cf for k8s] est prêt pour les petites équipes de développement, pour des applications non critiques. […] KubeCF, qui est plus mature, reprend l’existant de Cloud Foundry, mais il embrasse la même vision », affirme-t-il. « Les deux projets offrent l’expérience Cloud Foundry via Kubernetes à des utilisateurs ayant des besoins différents ».
Or, VMware entend faire de cf-for-k8s un composant essentiel de Tanzu Application Service, anciennement nommé Pivotal Cloud Foundry. Cette distribution de Cloud Foundry côtoie Kubernetes Grid, un moteur d’exécution de containers et Tanzu Mission Control, une console d’administration multicluster. VMware s’adresse pourtant à des organisations matures et de grands groupes dont les besoins de gestion de développement et de déploiements d’applications sont importants.
« Beaucoup d’organisations n’utilisent pas Kubernetes en production pour leurs applications critiques », reconnaît Ian Andrews, Vice-président Marketing pour le portfolio Tanzu. « Toutefois, le nombre d’entreprises qui adoptent Kubernetes est fortement croissant. Et si vous retirez l’exigence de la production, je pense que la plupart des organisations qui développent des applications utilisent des containers et envisagent sérieusement d’adopter Kubernetes ».
Selon Ian Andrews, il ne s’agit plus comme avec le Cloud Foundry traditionnel d’exécuter des milliers de containers sur des machines virtuelles pour des centaines d’applications raccordées à un seul environnement. Le responsable chez VMware considère que Kubernetes ne propose pas une architecture multitenant efficace, contrairement à Cloud Foundry. En conséquence, les entreprises subdivisent les environnements containerisés au niveau d’une équipe ou d’une application.
« Je peux maintenant déployer Cloud Foundry avec cf-for-k8s par-dessus ces environnements en dehors de la pile Cloud Foundry traditionnelle, et je passe d’une architecture qui nécessite au minimum 25 machines virtuelles pour un déploiement à haute disponibilité, à une autre qui ne comprend qu’une poignée de containers, avec un control plane entièrement containerisé », promet Ian Andrews.
D’après le responsable chez VMware, la distribution de cf-for-k8s supporte des applications traitant de gros volumes transactionnels. Selon un article de blog posté sur le site de la fondation, cf-for-k8s a besoin de 5 nœuds pour démarrer et se lance en moins de 10 minutes. La distribution supporterait déjà jusqu’à 1 000 applications déployées.
Malgré cette robustesse annoncée, une amélioration de la sécurité, la prise en charge des frameworks les plus populaires (Java, Node, Go, .Net Core, etc.), le projet est jeune. Il ne supporte pas encore les environnements Windows par exemple.
Reste aux clients de faire leur choix et d’anticiper les évolutions des projets au sein de la fondation. « Certains clients traditionnels qui utilisaient les distributions commerciales de Cloud Foundry avaient commencé à installer des infrastructures Kubernetes sans y intégrer CF, mais ils les liaient manuellement avec des outils CI/CD ou des composants open source. Nous observons qu’ils étendent leur stack Cloud Foundry sur Kubernetes avec KubeCF ou cf-for-k8s pour leurs développeurs », assure Thomas Di Giacomo.
Un long chemin de migration s’annonce pour les clients
Le PaaS Cloud Foundry traditionnel ne disparaît donc pas, pas tout de suite.
« À terme, je pense qu’une grande entreprise qui utilise plusieurs distributions de Cloud Foundry sur des VMs, ou avec Kubernetes, souhaitera unifier ses environnements et ne pas opérer des dizaines de plateformes différentes. La transition offerte par KubeCF simplifiera les plateformes de développement que les entreprises utilisent », estime le président de l’ingénierie chez SUSE.
« Chaque fois que vous faites une migration, c’est un changement d’architecture assez important. Vous voulez être prudent et réfléchi. C’est pourquoi tous nos utilisateurs finaux qui ont ces grands déploiements, comme l’administration britannique, sont très enthousiastes quant aux possibilités. Beaucoup d’entre eux testent déjà la nouvelle architecture et envisagent leur chemin de migration. Mais il leur faudra du temps pour effectuer la transition réfléchie dont ils ont besoin auprès de leurs fournisseurs commerciaux et leurs intégrateurs », prévient Chip Childers.
Ian Andrews promet que VMware continuera à mettre à jour sa version distribuée de Cloud Foundry sur des machines virtuelles. « De nombreux clients continuent à l’utiliser. Je pense qu’au cours des 12 prochains mois, nous verrons certains de ces clients qui ont commencé à adopter Kubernetes migrer vers notre distribution pour cette plateforme. Nous leur proposons bien évidemment un chemin de migration », assure-t-il.
Une compétition relancée
Ces deux projets vont également renforcer la compétition entre les coopétiteurs que sont VMware, SUSE, IBM et SAP, dans une certaine mesure. (Google a rejoint la fondation en mars 2020.)
Chip ChildersPrésident, Cloud Foundry Foundation
« IBM et SUSE commercialisent le projet KubeCF. VMware s’appuie sur cf-for-k8s. SAP a des déploiements massifs et teste à grande échelle la nouvelle architecture », résume Chip Childers. « Nous constatons une concurrence beaucoup plus active concernant les produits et services basés sur CF. Et c’est très sain. C’est exactement ce que les fondations open source souhaitent voir », ajoute-t-il.
SUSE, qui était l’un des premiers à proposer des distributions de Cloud Foundry pour Kubernetes doit s’adapter à cette nouvelle donne. « Certains de nos compétiteurs ont davantage un penchant cloud, notre approche est d’être le plus ouvert possible », vante Thomas Di Giacomo. « Nous avons développé et donné à la communauté l’interface de gestion Stratos (récemment passé en version 4.2), donc nous avons une expertise supplémentaire à apporter ».
Après la finalisation de l’acquisition de Rancher Labs, SUSE envisage de mêler les capacités de gestion multiclusters et multiclouds de Kubernetes offertes par Rancher, avec ses offres Cloud Foundry, selon le dirigeant.