Pour tenter de séduire les organisations habituées à GitHub et GitHub Actions, CloudBees s’inspire de la filiale de Microsoft afin de convaincre une plus large audience d’adopter sa plateforme SaaS.
Lors de son événement DevOps World Tour se déroulant à New York, CloudBees a officialisé le lancement de sa plateforme SaaS, nommée DevSecOps, reposant sur le framework open source Tekton. En sus de proposer une suite de fonctionnalités auparavant disponibles dans son offre entreprise (sécurisation, orchestration des pipelines, analytiques, Value Stream Management, feature flagging, etc.), l’éditeur entend reproduire le fonctionnement de GitHub Actions.
« Cette plateforme, fruit de plusieurs acquisitions et d’une stratégie longuement réfléchie, récupère ce qui a fait le succès de CloudBees. Nous offrons la possibilité d’avoir un écosystème ouvert sur les outils utilisés par nos clients », affirme Sacha Labourey cofondateur et Chief Strategy Officer chez CloudBees.
Cette ouverture, selon le cofondateur, dépend à la fois de Tekton et de Kubernetes.
Plateforme DevSecOps : CloudBees remplace Jenkins par Tekton
« Comme cela s’intègre à Kubernetes et ses ressources, l’aspect ouvert de la chose permet à nos clients d’utiliser des outils tiers pour observer le bon fonctionnement des pipelines, par exemple », illustre Sacha Labourey.
Tekton est souvent choisi par les éditeurs pour sa nature « cloud native », mais les éditeurs s’arrêtent à cette explication. Sacha Labourey est plus précis. « L’avantage de Tekton réside dans le fait que cette couche a été créée par-dessus Kubernetes ».
« Il n’y a pas de contrôleurs à gérer. Il n’y a pas de Daemon actifs en permanence pour vérifier l’exécution d’un pipeline », énumère-t-il.
CloudBees a développé et donné à la CI Foundation une version de Jenkins s’exécutant sur Kubernetes. Pour autant, Sacha Labourey considère que Jenkins sur Kubernetes serait difficile à maîtriser.
Tekton est davantage « event-driven » : une étape du pipeline va en « réveiller » une autre, d’après le CSO. « Il n’y a pas d’état partagé. C’est très efficace ».
« Nous utilisions un autre moteur CI au début du développement de la plateforme. Nous avons observé un gain de performance de l’ordre de 50 % en adoptant Tekton », assure-t-il.
Le responsable évoque là un « choix naturel » pour l’éditeur. Il y avait toutefois un obstacle majeur à relever.
Un presque GitHub Actions couplé à Tekton
« En revanche, Tekton dispose d’un langage d’expressions assez rupestre : c’est plutôt un moteur d’exécution », prévient le cofondateur.
Il fallait donc trouver un remplaçant familier pour les développeurs. CloudBees a jeté son dévolu sur la syntaxe de GitHub Actions pour en dériver un DSL.
« Nous nous sommes rendus à l’évidence que GitHub Actions était plus efficace dans le monde cloud, et que les ingénieurs chez nos clients ont appris à coder des flux Actions ou désirent le faire. Nous n’allions pas réécrire un langage spécifique ».
CloudBees ne veut toutefois pas copier purement et simplement le modèle GitHub. Les flux GitHub Actions s’exécutent après configuration d’un fichier YAML. Si ce langage est facilement lisible par un humain, il peut être pénible à utiliser.
CloudBees propose une interface graphique pour éditer les pipelines. « Il est possible de comparer en presque temps réel les pipelines dessinés dans l’éditeur et le fichier YAML ».
Une autre différence concerne la portabilité des charges de travail. « GitHub exécute les flux Actions dans des machines virtuelles sur Azure. Chez nous, comme les seuls prérequis sont Tekton et Kubernetes, les flux peuvent s’exécuter sur AWS, Google, Microsoft ou même on premise », distingue Sacha Labourey.
Aussi, la gestion des flux est associée à OPA, le moteur de règle open source imaginé par Styra. Cela permet de modéliser les autorisations au sein d’une organisation. « Nous pouvons par exemple attribuer une clé AWS d’un cluster à plusieurs comptes, mais limiter les actions possibles. Il s’agit d’exécuter des flux dans un conteneur associé à un contexte de sécurité », résume Sacha Labourey.
CloudBees SaaS peut être exécuté en mode multinenant, mais laisse la possibilité de la déployer en mode dédié chez certains clients.
D’autres éditeurs dont GitHub, Gitlab ou encore CircleCI permettent d’exécuter les pipelines CI/CD sur des infrastructures cloud hybrides.
Quelques arguments pour tenter de convaincre les clients existants
« Comme nous facturons à l’utilisateur, un client qui aurait toute l’offre logicielle CI/CD de CloudBees pourra utiliser les deux plateformes. »
Sacha LaboureyCofondateur et Chief Strategy Officer, CloudBees
« Certains éditeurs disent qu’ils sont hybrides, mais c’est un choix pilule bleue/pilule rouge », prétend Sacha Labourey. « Le client doit choisir entre le SaaS Cloud ou l’offre on-premise. Nous faisons les deux en même temps. Cela correspond davantage aux besoins de nos clients. Ce sont des grands comptes qui vivent parfois une certaine inertie, ils ont des actifs qui ne peuvent migrer vers le cloud ».
CloudBees sait très bien que ses clients n’abandonneront pas du jour au lendemain Jenkins. Tout comme Sacha Labourey sait très bien qu’il faut plusieurs années avant qu’une technologie soit largement adoptée en entreprise. « Nous permettons d’utiliser les deux plateformes en même temps. Si vous avez des jobs Jenkins, vous allez pouvoir les orchestrer à travers Tekton », promet Sacha Labourey.
Autre promesse de lancement, les clients ne paieront pas pour les deux plateformes. « Comme nous facturons à l’utilisateur, un client qui aurait toute l’offre logicielle CI/CD de CloudBees pourra utiliser les deux plateformes. Nous savons qu’aujourd’hui, les clients devront utiliser les deux », ajoute-t-il.
La disponibilité de la plateforme SaaS est attendue au 1ᵉʳ novembre.
