Cloud Foundry a choisi sa voie officielle vers Kubernetes

Un comité technique revu et corrigé (pour supporter cf-for-k8s)

Pour rappel, CFF avait dévoilé la mouture 1.0 de cf-for-k8s en octobre 2020. Neuf mois plus tard, et un cycle de mise à jour au rythme effréné, l’intention reste la même. Il s’agit de faire de cf-for-k8s l’évolution privilégiée de Cloud Foundry. La mise en place d’un nouveau comité technique également présenté lors de la conférence de presse va en ce sens.

On y retrouve Eric Malm et David Stevenson, respectivement responsable de ligne produits et Senior Staff Engineer chez VMware. Jan von Loewenstein, spécialiste de BOSH, et Stephan Merker sont développeurs chez SAP, tandis que Lee Porte est SRE Senior et leader technique de la PaaS du gouvernement britannique. Si la refonte du comité technique vise à améliorer « la supervision et l’orientation » des aspects techniques dans une démarche triple de « qualité », « d’intégrité des projets » et « d’inclusivité », la CFF matérialise son choix.  

Historiquement, Pivotal, racheté par VMware est le contributeur principal de Cloud Foundry. Childers assure que les employés de Pivotal représentaient 75 % au moment du rachat et qu’ils sont désormais « moins de 50 % » à travailler pour VMware. « Je considère cela comme une grande victoire pour la communauté », se réjouit-il. « Ces douze derniers mois, 66 organisations ont participé au développement de Cloud Foundry », ajoute-t-il plus loin. VMware et SAP sont des partisans de cf-for-k8s, contrairement à SUSE, et à IBM dans une moindre mesure.

Cependant, le président de la fondation évoque déjà l’alternative KubeCF au passé. « En général, je dirais que KubeCF était une passerelle. Il a toujours beaucoup de sens dans le contexte où il est utilisé. Mais nous commençons à voir une adoption active de cf-for-k8s ».

Selon Chip Childers, cette distribution plus légère de Cloud Foundry sur Kubernetes s’adresse aux grands groupes, mais surtout aux nouveaux venus, des startups ou des PME qui souhaiteraient exploiter la PaaS pour déployer leurs applications. Il y a quelques mois, la cohabitation pérenne entre les environnements cf-for-k8s et KubeCF semblait plus évidente pour l’intéressé. Aujourd’hui, cf-for-k8s est la voie officielle vers Kubernetes.

Avec Cloud Foundry, la migration vers Kubernetes demeure complexe

Concernant la tendance observée chez les PME, Julian Fischer, PDG d’Anynines, un éditeur allemand d’une version managée de Cloud Foundry, a exprimé un point de vue similaire lors de son intervention intitulée « Quand choisir Cloud Foundry plutôt que Kubernetes ? ». Ce titre légèrement provocateur, Julian Fischer l’a choisi, car il tente de relater dans ses propos la multitude d’interactions et de comparaisons possibles entre CF et Kubernetes. De son côté, il considère à nouveau que BOSH est une « technologie sous-cotée », même si elle est plus adaptée au déploiement d’applications depuis Cloud Foundry sur des milliers de machines virtuelles.

« Certaines entreprises qui ont déjà des environnements Cloud Foundry existants se demandent si elles doivent adopter et migrer vers le populaire Kubernetes. Il s’avère que c’est étonnamment difficile », relate-t-il. « L’on parle d’environnements qui comprennent des milliers de tenants et encore plus d’applications qui s’exécutent depuis une telle plateforme. En réalité, nous avons constaté l’annulation de multiples projets de migration, et les entreprises ont décidé d’étendre la durée de vie de leurs environnements Cloud Foundry », ajoute-t-il.

Les milliers de machines virtuelles de ces gros déploiements seraient remplacés par « énormément de clusters Kubernetes », provoquant davantage d’hétérogénéité. Julien Fischer recommande ces migrations quand l’entreprise a déjà adopté Kubernetes, ses extensions et les produits tiers qui l’accompagnent, quand les applications existantes ne respectent pas le principe des 12 facteurs et que le nombre de workloads sur des VM peut bénéficier d’un passage sur des containers. Sinon, le modèle centralisé de Cloud Foundry issu de l’implémentation de BOSH est davantage conseillé.

Chip Childers ne fait pas de mystère sur l’utilisation de la PaaS. Les principaux utilisateurs sont les grands contributeurs, c’est-à-dire les éditeurs et les fournisseurs de services IT. Ces acteurs-là administrent des existants de CF, c’est notamment le cas pour VMware qui se détache peu à peu de l’architecture reposant sur l’orchestrateur BOSH pour adopter le modèle cf-for-k8s. SUSE et IBM, eux, ont majoritairement développé KubeCF. En octobre 2020, Thomas Di Giacomo, CTO chez SUSE expliquait que son employeur commercialisait cette distribution de la PaaS sur Kubernetes depuis trois ans. Red Hat exploite une version de Cloud Foundry disponible sur OpenShift, elle aussi basée sur KubeCF.

De son côté, la maison mère IBM est un peu plus en retard. Dans une vidéo diffusée lors de Cloud Foundry Summit, Richard Johnson, Senior Technical Staff Member et Andrew Edgar, Senior Software developper chez IBM relatent leur projet de migration de BOSH vers KubeCF. « Nous souhaitons passer de VM BOSH à des instances basées sur KubeCF pour plusieurs raisons. L’une d’entre elles concerne l’économie que cela représente puisqu’il y a beaucoup moins de machines virtuelles à maintenir. C’est aussi beaucoup plus standard par rapport aux autres services IBM qui sont désormais tous basés sur Kubernetes, ce qui permettra à nos opérateurs d’administrer Cloud Foundry plus aisément », argumente-t-il.

Andrew Edgar explique que le fournisseur a souhaité mettre en place une migration « essentiellement transparente » pour ses clients. 

L’architecture d’IBM comprend un contrôleur de cellules BOSH incluant plusieurs cellules de déploiement Diego (alors qu’Ereini est désormais privilégié), associé à un control plane BOSH et des bases de données sur des serveurs bare-metal. « Pour migrer vers Kubernetes, nous allons d’abord transférer les cellules Diego dans un cluster KubeCF et le connecter au control Plane BOSH », expose Andrew Edgar.

Dans un premier temps, le contrôleur de cellules BOSH et l’instance KubeCF équivalente cohabiteront permettant de déployer les applications soit sur des machines virtuelles, soit dans des instances Kubernetes. « Puis, nous arrêterons les cellules du côté BOSH. Quand les cellules tombent, les applications migrent sur les instances Kubernetes, à l’instar d’un déploiement continu ». Ensuite, les équipes d’IBM s’attaqueront au remplacement du control plane BOSH par son équivalent KubeCF.

Mais cela demande de développer un plug-in DNS spécifique pour faire transiter les cellules de BOSH vers KubeCF. De même, les mises à jour applicatives ne dépendent pas exactement des mêmes mécanismes sur Kubernetes et réclament d’ajuster les composants pour éviter les erreurs au moment de déployer un correctif ou de nouveaux éléments. Les développeurs de SUSE a aidé l’entreprise a préparé cette migration afin de faire en sorte que le comportement du control plane de KubeCF soit le plus proche possible de celui de BOSH.

BOSH critiqué, mais maintenu

BOSH ne disparaîtra pas d’un claquement de doigts. SAP, qui a choisi de soutenir cf-for-k8s, voit le projet comme « l’avenir de Cloud Foundry ». Dans les faits, il a repris en partie le flambeau de la maintenance de BOSH dont une partie des composants actifs sont passés en mode support l’année dernière (d’autres tels BOSH Openstack CPI ont été dépréciés). En juin dernier, Felix Riegger, développeur chez SAP évoquait le fait que la base installée de Cloud Foundry, le cœur même de la Business Technology Platform (BTP), représentait « plus de 42 000 VMs » sans compter les environnements de développement et de tests.

L’éditeur allemand s’occupe plus particulièrement du maintien de Bionic StemCell, c’est-à-dire l’OS de ces VM basées sur Ubuntu Bionic (et avant cela, Ubuntu Xenial). VMware a décidé d’arrêter le support de cette technologie en mai 2021, laissant planer la menace de vulnérabilités de sécurité. À l’avenir, SAP compte sur la communauté de CFF pour l’aider dans cette tâche.

« Notre communauté s’est engagée pour ses membres et pour les utilisateurs finaux et considère que l’architecture de Cloud Foundry basé sur BOSH est très importante. SAP est un bon exemple. L’éditeur a un énorme environnement basé sur cette architecture. Il investit davantage pour s’assurer qu’il est bien entretenu, qu’il est maintenu à jour et qu’il continue à évoluer », vante Chip Childers.

« La même chose, franchement, s’applique à VMware. Une grande partie de leurs revenus est encore basée sur l’architecture BOSH. Ils se sont engagés envers leurs clients et nous les voyons donc tenir leur promesse en amont avec le concours de la communauté. Cette architecture très mature, stabilisée et soutenue par la communauté n’a pas une fin de vie programmée à ce stade », martèle-t-il.