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

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.