Cloud Foundry Summit : BOSH devient aussi un standard pour déployer Kubernetes

Le projet Kubo, initié par Google et Pivotal, devient Container Runtime, le Caas de la fondation Cloud Foundry, et Application Runtime, son Paas. Leur point commun : BOSH qui se transforme en un socle universel de déploiement et de monitoring.

La communauté Cloud Foundry a décidé de capitaliser sur le projet BOSH. A l’occasion du Cloud Foundry Summit qui se tient actuellement à Bâle, la fondation derrière l’un des projets Open Source  les plus actifs dans le monde du Cloud Open Source, a donné vie au projet Kubo en l’affublant d’un nouveau nom de baptême : Container Runtime. Un ajustement marketing clé pour la fondation qui a également entrainé le changement de nom d’Elastic Runtime – l’essence même du Paas Cloud Foundry - en Application Runtime. Sous l’ère Abby Kearns, présidente de la fondation depuis deux ans, la fondation aura donc monté d’un cran dans la structuration de son écosystème (voir encadré) et de ses membres en donnant du poids aux industriels. Mais elle aura également insufflé une structuration de l’offre (comprendre « productisation »), alors que certaines communautés peinent à quitter leur image d’agrégat de projets Open Source.

Container Runtime, ex-Kubo, est un projet Open Source initié par Google et Pivotal et donné à la Cloud Foundry Fondation en juin 2017. Son principe : industrialiser les déploiements et la gestion du cycle de vie de l’orchestrateur de containers Kubernetes à partir de BOSH. BOSH, quant à lui, est un autre projet Open Source, né dans le sillage du projet de Paas Cloud Foundry, au sein de la fondation Open Source. Son rôle est de gérer et de monitorer les déploiements distribués d’applications et multi-cloud sur le Paas – à l’origine, il a également été conçu pour s’adapter à toute autre application. BOSH correspond en fait à une tour de contrôle opérationnelle des applications déployées en garantissant un maintien des workloads, de leur bon fonctionnement et de leur bonne coordination.

Logiquement, BOSH était devenu l’un des projets les plus actifs de la Cloud Foundry Foundation – nous avions pu le voir lors de l’édition 2016 du Cloud Foundry Summit Europe. Son approche, censée simplifier les déploiements et la maintenance, son modèle descriptif de configuration ainsi que l’abstraction multi-Iaas (du moins Google, AWS et VMware vSphere), avait séduit la communauté en ôtant une partie de la complexité des déploiements multi-cloud de Cloud Foundry.  Il apparait donc comme une aubaine pour Kubernetes, plutôt connu pour sa complexité à opérer en production. On lui reproche notamment son absence de possibilités natives de tolérance aux pannes pour les composants du cluster, de monitoring partiel de l’état de santé d’un cluster, et la difficulté d’effectuer des mises à jour continues (« rolling ») sur les grands clusters. Autant de trous dans la raquette qui pourront être désormais pris en compte via le Container Runtime de la fondation.

Restera alors à déterminer les cas d’usage de ces deux runtime. Si Abby Kearns parle de cohabitation possible et surtout d’un choix de déploiement plus vaste pour les utilisateurs, les entreprises devront toutefois évaluer les types de workloads qu’elles souhaitent placer sur l’une ou l’autre. « Les entreprises ont besoin de différents niveaux d’abstraction pour gérer leur workload », résume Fred Melo, directeur technique chez Pivotal. Celle-ci est en effet plus élevée avec un Paas  (Application Runtime) qu’avec un modèle de type Caas (Container-as-a-service – Container Runtime), illustre-t-il.  Le Paas crée automatiquement des containers (dans l’environnement Diego/Garden pour Cloud Foundry), le second ne fait qu’orchestrer des containers apportés par les développeurs. Si avec le Paas, on réduit donc la complexité, on abaisse également l’efficacité et la flexibilité, car l’approche est moins granulaire qu’avec une manipulation directe des containers.

Remplacer Chef ?

Chez les utilisateurs, faire de BOSH un socle transversal permet de se soulager des tâches opérationnelles pour se concentrer sur le métier. Ce que rapporte Julian Fischer, CEO de la société Anynines, qui développé un service Cloud de base de données. « Nous avons migré toutes nos recettes Chef vers BOSH (Une transition demandée d’ailleurs par son équipe Ops, NDLR). Nous voulons être capables de décrire les processus que nous voulons, et je me moque que ce soit pour Kubernetes, les containers ou les VM. Notre objectif est de proposer une base de données et de ne pas avoir à tout ré-implémenter à chaque fois », résume-t-il.

L’autre gain apporté par BOSH à Kubernetes pourrait également permettre aux containers de progresser dans les environnements de production. Car comme le révèle une étude de la Cloud Foundry Foundation, si les containers suscitent un vrai engouement, seuls 25% des utilisateurs de Cloud Foundry interrogés ne les ont déployés en production, ce qui ne représente qu’une progression de 3 points en un an. De quoi laisser une possibilité d’amélioration, en effet.

L’écosystème se structure autour d’une place de marché

Le projet Cloud Foundry réunit quelque 2 783 contributeurs, dénombre la fondation, montrant une « vélocité importante de sa communauté ». Quelque 93 085 commits ont été effectués ces derniers 24 mois, a rapporté Abby Kearns, la directrice exécutive de la Cloud Foundry Foundation.  La fondation a également accueilli 5 nouveaux membres, dont la chaîne de magasins Home Depôt, Volkswagen, ou encore l’éditeur de base de données Time-Series InfluxDB.

Enfin, dans un effort de mieux identifier les acteurs de l’écosystème, la fondation a également profité de son événement pour présente une beta d’une place de marché, « The Foundry », qui réunit partenaires, intégrateurs, formateurs, services et add-ons pour Cloud Foundry. Plus de 600 y sont aujourd’hui centralisés.

Pour approfondir sur PaaS

Close