LEBIGDATA.FR I.A, Cloud & Cybersécurité
Lors du Cloud Foundry Summit se déroulant à Bâle du 9 au 11 octobre, l'ONG a présenté deux nouveaux projets en lien avec Cloud Foundry Container Runtime : CF Containerization et Eirini. Deux composants qui ne font pas le bonheur de tous les distributeurs.
Elles n'ont eu le droit qu'à un slide et une présentation rapide lors du Keynote d'ouverture du Cloud Foundry Summit et pourtant ce sont les deux annonces phares de ce sommet.
Eirini et CF Containerization : les deux nouveaux projets de la fondation
Plus enclins à évoquer le besoin de synergie des membres de sa communauté que les détails techniques de ses deux projets, les dirigeants de l'ONG nous renvoient au communiqué de presse. On y découvre alors CF Containerization et Eirini.
Tous deux ont été « validés par deux des comités de gestion de projets (PMC) Cloud Foundry », peut-on lire dans ce communiqué de presse. On y apprend que CF Containerization sera incubé par le comité en charge de BOSH, tandis qu'Eirini poussé par IBM, SAP et SUSE.
Eirini a pour but d'offrir aux développeurs une commande simple pour faciliter la mise en production des applications en les superposant à Kubernetes. Au bout du développement, ils n'ont qu'à taper cf push dans l'invite de commande pour pousser les applications en production.
CF Containerization permet de « créer des packs de versions Cloud Foundry BOSH intégrés à des containers et de déployer ces derniers dans Kubernetes », toujours selon la même source. « Il s'agit de déployer Cloud Foundry Application Runtime dans les clusters Kubernetes en place ». Le site web offre un petit peu plus de détails concernant la méthode employée. CF Containerization converti les versions de BOSH en images Docker. Puis, le système dialogue avec Helm Charts, le gestionnaire d'applications pour Kubernetes afin de rendre effective les installations sur les clusters Kubernetes. Pas très simple.
Alléger le poids des infrastructures
Thomas Di Giacomo, CTO de Suse nous explique la logique derrière ce projet. Son employeur, originellement spécialisé dans la distribution de versions de Linux, est à l'origine de ce dernier. Di Giacomo est lui même une des têtes pensantes de l'intégration de CF Contenainerization au sein du catalogue de Cloud Foundry. Le membre du board de Cloud Foundry, de la Fondation Linux et de Cloud Native Foundation affirme :
« La PaaS Cloud Foundry est une très belle solution, mais lourde à installer. Elle réclame généralement de mettre en place une vingtaine de machines virtuelles pour commencer. Avec CF containerization, on bénéficie davantage d'agilité, c'est plus facile d'installation. L'intérêt, c'est également d'injecter Cloud foundry dans des solutions contenairs existantes type Azure ou Google. Ainsi, les développeurs ne sont pas obligés d'installer toute la plateforme et nous passons de vingt à une ou deux VM », affirme Thomas Di Giacomo.
Il s'agit d'intégrer nativement Cloud Foundry au sein de Kubernetes, « sans créer un système de contrôle supplémentaire par-dessus Kubernetes », mais aussi « de migrer les applications legacy sans avoir à installer toute la stack Cloud Foundry».
Marier Cloud Foundry et Kubernetes
Un rapprochement technologique de Cloud Foundry et de Kubernetes va de pair avec un rapprochement des fondations responsables de ces deux projets. Cela semble naturel : Cloud Foundry et Cloud Native Cloud Computing Foundation sont des sous-groupes de la Fondation Linux.
Selon le CTO de Suse, cette tendance à la collaboration a commencé avec l'ajout de l'Open Service Broker API qui permet d'avoir des services utilisables sur Kubernetes et Cloud Foundry. « Aujourd'hui, nous délivrons Cloud foundry sur Kubernetes : nous utilisons des outils communs, c'est la même infrastructure. Notre solution est une sorte d'extension Cloud Foundry à Kubernetes. Par exemple, Les Build pack sont développés en commun entre CFF et CNCF, afin de ne pas refaire des containers dans CF que CNCF a déjà fait avec Kubernetes. ».
Selon lui, CF Contenairization vient améliorer l'existant : « Kubernetes est très bien pour gérer des containers au niveau de l'infrastructure, mais cela manque d'outils pour les développeurs. Cloud Foundry est lui très bien pour les développeurs, mais la solution existante pour l'orchestration des containers (Diego) n'était pas aussi bonne. Il s'agit de marier le meilleur des deux mondes ».
Une approche qui ne convient pas à tous les distributeurs
Cette vision n'est pas partagée par tous les acteurs membres de Cloud Foundry. « Je pense que les projets sont intéressants académiquement parlant, mais je ne pense pas qu'ils règlent un problème auquel un client se confronte aujourd'hui. Finalement cela pourrait en créer de nouveaux qu'il ne rencontrerait pas autrement », déclare Ian Andrews, Vice président Produit de Pivotal.
Historiquement Pivotal est un fournisseur de distributions Linux. D'année en année, la firme est devenue un leader de la distribution de solutions open source. Lors du Cloud Foundry Summit, la plupart des entreprises qui présentaient leurs avancées dans l'adoption de ces technologies utilisent une distribution Pivotal. L'alliance Renault Nissan Mitsubishi exploite cette distribution dans ces voitures connectées, l'avionneur Boeing et le transporteur Air France KLM y développent des applications métiers ou encore Thales s'en sert pour développer des MVP plus rapidement (3 mois au lieu de plusieurs années).
« Containeriser le control plane de Cloud foundry et le faire fonctionner par-dessus Kubernetes, c'est présupposé que Kubernetes est déjà installé, opérationnel et maintenu ».
Or, le vice-président Produit de Pivotal considère que BOSH, l'outil de gestion unifiée des mises à jour et du déploiement d'applications, est essentiel. C'est cet outil qui selon lui est le plus adapté au déploiement de clusters Kubernetes.
Pour Ian Andrews, il s'agit de se passer de Diego, un élément que des acteurs comme SUSE, IBM ou SAP n'ont pas intégré dans leurs offres.
Le Vice Président reste toutefois ouvert à l'expérimentation : «Nous n'avons pas besoin d'être d'accord sur toutes les spécifications techniques. Ce que je trouve intéressant avec Eirini et CF Contenairization c'est que ce sont des idées. Voyons si cela peut fonctionner. »
Cette tension n'a pas grand-chose à voir avec les développeurs membres de la communauté. Il s'agit de différenciations techniques portées par des entreprises qui souhaitent satisfaire une clientèle davantage tournées vers Kubernetes. Il s'agit d'adapter les infrastructures aux projets en cours.
Une fondation à la recherche de l'équilibre
De son côté, la fondation Cloud Foundry défend une certaine neutralité. « Nous ne sommes pas là pour expliquer que telle solution ou telle offre d'une entreprise est meilleure qu'une autre. Ce sont aux entreprises de trouver les bons partenaires technologiques dans leur transformation numérique en cours », affirme Chips Childers, CTO de Cloud Foundry Foundation.
Concernant les divisions autour des technologies, le CTO considère que c'est l'évolution naturelle d'une technologie naissance. La PaaS open source est disponible depuis quatre ans et il « s'attend à des consolidations prochaines ».
Cependant, il affirme que Diego dispose d'une meilleure gestion de l'approche Multi-Tenant que Kubernetes. Clairement, même à la tête de l'ONG, la direction que va prendre cette technologie n'est pas claire.
Pour Abby Kearns, directrice exécutive de la fondation, « l'un des plus grands défis à relever à celui de trouver l'équilibre entre émulsions technologiques, la proposition de solutions robustes aujourd'hui et le fait d'avoir un œil tourné vers l'avenir ».
- Partager l'article :
