Sergey Nivens - Fotolia
Kubernetes complique (encore) le développement de Cloud Foundry
La communauté de Cloud Foundry a commencé à porter son interface de développement sur l’infrastructure de Kubernetes, mais n’a pas encore choisi le chemin pour opérer la transition.
Cloud Foundry est entré dans une phase de développement sans précédent, les responsables en amont cherchant à remplacer le moteur d’infrastructure de leur plateforme sans ralentir les développeurs en entreprise, qui en dépendent.
Ce processus a commencé sérieusement l’année dernière, après des années de débat sur la nécessité de changer de cap dans le développement des plateformes hébergées sur le cloud. Certaines parties de la communauté Cloud Foundry avaient commencé à se pencher sur Kubernetes avec le projet Kubo en 2017, un effort précoce de Pivotal, qui fait maintenant partie de VMware, pour rejoindre les deux technologies. Mais pas plus tard qu’en 2018, l’ensemble des utilisateurs de Cloud Foundry n’avait pas encore décidé s’il fallait remplacer l’infrastructure déjà développée pour la PaaS par des équivalents de Kubernetes.
Au printemps 2019, la conversation a connu un tournant après la présentation des premières versions du projet Eirini lors d’un sommet Cloud Foundry peu fréquenté à Philadelphie. Un peu plus d’un an plus tard, après un changement de direction au sein de la fondation, l’édition virtuelle 2020 du sommet – de rigueur en pleine pandémie – s’est recentrée sur le développement de la plateforme pour la communauté, plutôt que de son évolution pour les entreprises.
Kubernetes est la voie à suivre, mais les chemins sont nombreux
Cette communauté travaille désormais sur la base d’un consensus selon lequel Kubernetes est la voie à suivre, selon Chip Childers, qui a pris la relève de l’ancienne directrice de la Fondation, Abby Kearns, au début du mois d’avril.
Chip ChildersDirecteur, Cloud Foundry
« Notre communauté s’est réorientée vers l’architecture de nombreux composants de sous-systèmes pour tirer parti de Kubernetes », déclarait-il dans une interview avec SearchITOperations [Propriété de TechTarget, également propriétaire du MagIT]. « Tout va dans la même direction ».
Les versions commerciales Kubernetes telles que Red Hat OpenShift d’IBM et les services hébergés par des fournisseurs cloud comme GKE offrent déjà une expérience de développement optimisée sur Kubernetes. Mais la communauté de Cloud Foundry a encore une chance d’apporter une valeur ajoutée grâce à ses années d’expérience dans le développement de PaaS, selon Stephen O’Grady, analyste principal et cofondateur chez RedMonk. « Cloud Foundry propose ce type d’expérience optimisée depuis longtemps déjà » assure Stephen O’Grady.
« La question n’est plus de savoir si, ou même, comment faire fonctionner Cloud Foundry et Kubernetes ensemble, mais plutôt comment CF peut fournir des abstractions au-dessus et autour de Kubernetes pour améliorer l’expérience globale du développeur et de l’opérateur ».
Parmi les efforts récents de la Fondation pour atteindre cet objectif, on peut citer la sortie de la version 7 de l’interface de ligne de commande (CLI) de Cloud Foundry. La nouvelle version, qui pourrait être automatiquement adoptée par les versions commerciales en aval de CF telles que les produits PKS et Tanzu de VMware/Pivotal, doit faciliter les déploiements d’applications en continu, compatibles avec les containers. Elle prend également en charge des déploiements d’applications plus complexes, en plusieurs étapes, ainsi que des processus de side-car pour apporter des fonctionnalités de maillage de services.
Vers la fusion entre KubeCF et CF-For-K8s : SUSE et Pivotal toujours à la recherche de l’équilibre
La Cloud Foundry Foundation est désormais unie autour d’un objectif : orienter le développement de sa plateforme vers Kubernetes, mais l’état d’avancement de ce travail reste encore fragmenté, presque deux ans après l’annonce des projets CF Contenairization et Eirini.
L’année dernière, l’événement s’est concentré sur la sortie du projet Eirini, qui permet aux développeurs utilisant le CFAR (Cloud Foundry Application Runtime) de choisir entre Kubernetes et les utilitaires Diego et Garden de Cloud Foundry pour la gestion et la programmation des containers. Eirini a depuis été combiné avec le projet Quarks, qui compile le CFAR dans des conteneurs plutôt que dans son format original de machine virtuelle.
Deux autres projets ont également débuté l’année dernière pour faciliter le déploiement automatique de la version conteneurisée de Cloud Foundry sur l’infrastructure de Kubernetes.
Le plus mature de ces efforts est KubeCF, un projet mené par SUSE qui a atteint une version 1.0 prête pour la production, et a été mis en incubation dans la Cloud Foundry Foundation en mai. KubeCF utilise l’opérateur de Cloud Foundry développé au sein de la Cloud Native Computing Foundation, et s’appuie toujours fortement sur BOSH, l’outil de base de CF pour la fourniture et l’orchestration de l’infrastructure basée sur les machines virtuelles.
Le projet CF-for-K8s, mené par VMware/Pivotal, a également été publié ce printemps dans la version 0.1.0, prête uniquement pour une utilisation en « sandbox ». Ce projet élimine BOSH et fournit des interfaces directement entre CFAR et des composants reconçus pour être utilisés avec Kubernetes, comme kpack, un utilitaire de conditionnement de containers conçu pour Kubernetes ; tandis que KubeCF utilise toujours les buildpacks existants de Cloud Foundry. CF-for-K8s remplace également le routeur Go de Cloud Foundry par le maillage de service Istio, et un nouveau CLI kapp pour le précédent CLI BOSH.
Troy TopnikChef de produit senior, SUSE
« Ces projets ne sont pas opposés », écrit Troy Topnik, chef de produit senior chez SUSE, dans un article de blog sur le site de Cloud Foundry annonçant CF-for-K8s. « Ils sont convergents ».
L’article de Topnik, et les présentations au salon de cette année, ont positionné KubeCF comme une rampe d’accès plus facile à l’intégration de Kubernetes pour les PaaS Cloud Foundry existants, tandis que les CF-for-K8s représentent un saut plus important et à plus long terme par rapport à l’utilisation de BOSH.
Cependant, les responsables du projet Cloud Foundry ont admis – lors d’une session du panel 2020 – qu’en fin de compte, la présence de deux projets de développement distincts, ayant des objectifs similaires au sein de la fondation, est loin d’être idéale.
« Quelqu’un venant du monde BOSH va bénéficier d’un atterrissage en douceur dans KubeCF… parce que vous n’auriez pas à apprendre tous les concepts de Kubernetes », considère Simon Moser, membre du personnel technique d’IBM, qui va intégrer KubeCF dans le service IBM Cloud Foundry. « Alors que quelqu’un qui commence un projet greenfield (sans contrainte imposée par l’existant) ou… qui cherche à utiliser tous les derniers concepts Kubernetes, je pense que CF-for-K8s sera la solution la plus naturelle ».
« Cela dit », ajoute Simon Moser lors de la table ronde, « J’espère vraiment que lorsque nous nous réunirons à nouveau dans un an, ces deux projets seront fusionnés ».
De longs adieux à BOSH
Alors que les priorités de la communauté en matière de développement de la plateforme CF changent, plusieurs participants ont exprimé, lors de séances de questions-réponses en ligne, leurs inquiétudes quant à l’avenir à long terme de BOSH.
BOSH a l’avantage de fournir des machines virtuelles bien isolées et nous avons des clients qui ne veulent pas mettre en conteneur leurs instances de services de données », déclare Julian Fischer, PDG d’Anynines GmbH, une société allemande qui fournit des services informatiques gérés et une PaaS basée sur la technologie Cloud Foundry. « Lorsque ce problème sera résolu, il est possible que BOSH doive se transformer ou qu’il perde de sa pertinence avec le temps. J’espère que ce sera la première des deux options ».
Que BOSH évolue ou disparaisse, il faudra un certain temps à Kubernetes pour s’adapter à l’utilité d’un approvisionnement multicloud facile et standardisé, considère Julian Fischer, lors d’un entretien.
Julian FischerPDG, Anynines GmbH
« Nous vendons toujours des environnements BOSH et ils seront là pendant des années », affirme-t-il. « Si je construisais un nouvel environnement aujourd’hui, je choisirais peut-être encore des VM, car elles sont très bien isolées et fonctionnent à merveille à l’échelle ».
Des efforts sont en cours dans la communauté de Kubernetes pour remplir la promesse d’agnosticisme de l’orchestrateur de containers, mais ils sont, à l’image de l’API Cluster, encore à un stade précoce.
BOSH crée des machines virtuelles, des disques virtuels et certaines infrastructures de réseau, mais les utilisateurs ont encore besoin d’utilitaires IaC tels que Terraform pour étoffer pleinement un nouvel environnement d’infrastructure. « Cela prend du temps et des ressources, mais une fois établi, BOSH intègre son interface Cloud Provider (CPI) avec les API des infrastructures cloud, afin d’effectuer les décommissionnements beaucoup plus rapidement et de manière plus fiable que tout ce qui est possible avec Kubernetes », tranche Julian Fischer.
Une autre différence entre les CPI BOSH et l’API Cluster est que cette dernière intègre également la couche infrastructure-as-code – par exemple, l’API Cluster pour AWS génère des modèles CloudFormation. Cette couche d’abstraction supplémentaire augmente le potentiel « d’hétérogénéités disgracieuses » dans les déploiements multicloud de Kubernetes, considère Julian Fischer.
D’une certaine manière, Kubernetes répète le développement de la plateforme de Cloud Foundry, mais Julian Fischer ne voit pas Kubernetes comme « l’ennemi ».
« Bienvenue dans le monde IT », déclare-t-il. « Nous sommes dans l’industrie de la mode, et Kubernetes est la dernière tendance à suivre (“Kubernetes is the new black”, en VO).