Kubernetes + Open Service Broker = la solution multicloud ultime ?
Kubernetes s'impose désormais comme la solution d'orchestration applicative phare des pure players du cloud comme des entreprises traditionnelles. Les premiers l'ont bien compris. Tous affichent désormais des offres de CaaS (Containers as a Service) majoritairement basées sur la plateforme open source.
Mais jusqu'à présent, chaque cloud développait ses propres API, y compris pour donner accès à ses services managés à base de Kubernetes. D'où l'idée introduite par le projet Open Service Broker de proposer des catalogues de services dont les API seraient communes à tous les clouds, qu'ils soient publics ou privés. Objectif : fournir des passerelles uniformes quel que soit le provider. La promesse étant de pouvoir consommer par exemple un service de base de données de la même façon, sans avoir à retoucher son application, qu'il soit proposé sur AWS, Microsoft Azure ou Google Cloud Platform.
"Kubernetes se veut universel" insiste Guilhem Lettron, fondateur de Barpilot et site reliability engineering indépendant. "Grâce à ce socle, une application peut tourner sur la machine d'un développeur, un serveur ou une infrastructure cloud. Cette portabilité nous pousse à gérer les ressources IT dans une logique où on ne veut pas connaître la plateforme de l'hébergeur mais uniquement des API de pilotage, et si possible standard." Grâce à une telle surcouche, l'orchestrateur permettrait d'automatiser le dimensionnement de la puissance informatique nécessaire à une application Kubernetes quel que soit le cloud choisi, de manière totalement transparente. "Ainsi associé à Open Service Broker, Kubernetes pourrait devenir une API pour les gouverner tous", résume l'expert.
Vers un standard pour le brokering Kubernetes
Initié au sein du projet open source Cloud Foundry porté par Pivotal, Open Service Broker est devenu un chantier de développement communautaire fin 2016 lors du lancement par la Cloud Foundry Fondation de l'Open Service Broker API Project (OSB API). Les spécifications initiales du framework ont alors été transférées par Cloud Foundry vers Github, l'objectif étant d'étendre la couverture des spécifications et surtout d'accroître son adoption auprès des fournisseurs de cloud. Aux côté de Pivotal, les premiers membres du comité de gestion du chantier furent Fujitsu, Google, IBM, Red Hat et SAP.
"Nous allons vers l'émergence de marketplaces de services managés reposant sur Kubernetes"
Depuis la V2.12 sortie en juin 2017, OSB API s'est affranchie de la plateforme Cloud Foundry. Désormais, la communauté Kubernetes est très impliquée dans son développement. IBM et Google se sont lancés dans la mise en œuvre d'API compatibles avec OSB sur leur offre de cloud. C'est également le cas de Microsoft depuis décembre 2017 via son service OSB for Azure (OSBA). Alibaba en a fait de même quelques mois plus tard.
Certes, tous les fournisseurs de cloud ne l'implémentent pas encore, mais OSB API semble bel et bien s'imposer comme un standard de facto pour la communauté Kubernetes. "Ce concept de broker de services pour Kubernetes est extrêmement intéressant, mais n'est pas totalement nouveau. On retrouvait ce principe chez Heroku et Pivotal. Ce qui est intéressant avec OSB API, c'est que l'on a un standard qui va généraliser le concept chez tous les providers", analyse Christophe Sauthier, CEO d'Objectif Libre.
OSB API prend tout son sens au sein des clouds publics qui vont pouvoir proposer via ce standard l'ensemble de leur catalogue. "Tous avaient déjà leurs propres CaaS. Avec OSB, ils vont pouvoir donner plus largement accès à leurs services managés. Cela se traduira par l'équivalent de marketplaces comparables à celles des smartphones Android et iOS, mais offrant des applications cloud à base de Kubernetes." Pour l'expert, si l'essor d'OSB API marque le début d'une nouvelle ère pour Kubernetes, il pourrait bien avoir un revers à cette simplicité. "Le danger, c'est que les fournisseurs mettent en avant leurs offres propriétaires avec le danger pour les clients de se retrouver pieds et poings liés à ces providers. En ce sens, le service broker pourrait devenir le meilleur moyen pour eux de verrouiller les clients sur leur plateforme", argue Christophe Sauthier.
Un référentiel pour le cloud hybride
Les clouds publics ont ainsi tout intérêt à supporter OSB API pour promouvoir leurs propres offres managés Kubernetes. Reste qu'Open Service Broker présente aussi un intérêt pour les entreprises qui privilégient une approche de cloud privé ou d'hybridation. "OSB API prend également tout son sens sur un cloud interne, basé sur OpenShift par exemple" explique Christophe Sauthier. "Les grandes entreprises vont vers le DevOps et mettent de plus en plus à disposition de leurs développeurs des infrastructures informatiques hybrides sous forme de catalogue d'API. C'est exactement ce que leur offre OSB. Via ce framework, elles vont pouvoir gérer ce catalogue, y ajouter des ressources internes, des ressources sur des cloud publics."
Red Hat participe activement au développement d'OSB API. Le catalogue de services de sa technologie de PaaS OpenShift repose déjà sur ce socle. Grâce à cette couche, il peut référencer à la fois des services cloud portés par le CaaS de Red Hat, par des clouds publics ou encore par la DSI. Un moyen pour les entreprises de garder le contrôle de leur portefeuille de services cloud.