HashiCorp tente d’adapter Waypoint pour les développeurs

Même nom, nouvelle formule

Désormais nommé HCP Waypoint, le nommage signe son ralliement à la gamme de produits HashiCorp, mais aussi la fin de son accès en open source. Le dépôt GitHub a été archivé le 8 janvier dernier.

De fait, il est rattaché à HCP Terraform. Il s’agit de s’appuyer sur des templates, réutilisables donc, écrits avec le DSL d’HashiCorp (HCL) pour déployer des applications.

Ces templates sont mis à disposition des développeurs par des ingénieurs plateforme. « Un template peut consister en un modèle de dépôt de code configuré avec le framework front-end par défaut de votre organisation, les bibliothèques de linting et les pipelines CI/CD », illustre la documentation de l’éditeur. « Autre exemple, l’on peut configurer un cluster Kubernetes prêt pour la production ou un framework d’API backend configuré pour le serverless ».

Ces templates peuvent s’appuyer sur les fichiers .tf répertoriés dans les workspaces HCP Terraform. Ces « modules » doivent être correctement déclarés (il convient de citer les providers, notamment) pour s’adapter à la nomenclature de Waypoint.

En effet, l’UI des workspaces permet de sélectionner des fichiers Terraform existants pour en faire des « modules no-code », ou bien il est possible de créer ces modules de pied en cap sans écrire une ligne de HCL.

Il faut ensuite créer des définitions d’extensions pour certains services, ainsi que des actions.

« Alors qu’un modèle crée une infrastructure nécessaire à chaque application, un module d’extension crée une infrastructure dont seules certaines applications auront besoin », précise la documentation. Cela peut être le cas d’une configuration DNS spécifique avec Amazon Route 53, une instance de stockage objet S3, une couche de cache Redis ou encore une base de données.

GM Financial, la branche de services financiers de General Motors, utilise les add-ons pour gérer l’intégration des secrets et des accréditations depuis HCP Vault Secrets, sans que les développeurs aient à les manipuler.

Les actions, encore en bêta, correspondent à l’idée originelle derrière Waypoint, par exemple « déclencher l’exécution d’un build, déployer une application, modifier un feature flag » ou encore sauvegarder un backup. Comme les templates, les actions sont réutilisables. Il sera possible d’utiliser des actions tierces, en provenance de GitHub Actions, Jenkins ou autres. Une API spécifique a été mise en place par HashiCorp.

Ces actions doivent permettre de configurer des flux de travail de référence (« golden workflows ») orchestrés par les ingénieurs plateforme (ou sysOps).

Au fur et mesure que les fichiers .tf sont mis à jour, certaines variables, par exemple l’ajout d’un agent d’observabilité, peuvent être reportées semi-automatiquement dans les modules no-code dépendants et sont activables d’un clic par les développeurs. Dans la démonstration de HashiCorp, il s’agissait d’activer la supervision d’une application Java déployée avec le framework Spring Boot sur AWS avec CloudWatch.

Waypoint, un positionnement difficile

HashiCorp n’est pas le premier sur ce terrain. L’interface utilisateur de Waypoint et l’API semblent être une réponse aux nouveaux concurrents tels que Harness, Pulumi et System Initiative, qui pourraient tenter les clients de HashiCorp grâce à leur facilité d’utilisation, selon Andi Mann, directeur technique mondial et fondateur de Sageable, une société de conseil en technologie située à Boulder, dans le Colorado.

« La simplification, la facilité de déploiement et la collaboration entre les Ops et les développeurs [sont les points sur lesquels] System Initiative, mais aussi certaines start-ups plus anciennes se concentrent – comme Pulumi, par exemple, ou Harness. Elles sont vraiment compétitives », avance-t-il.

Or l’adoption d’un service comme Waypoint réclame une certaine gymnastique : les sysOps doivent respecter le standard de configuration dicté par l’éditeur.

Aussi, les entreprises n’ont pas forcément attendu HashiCorp pour bâtir des plateformes rassemblant des composants accessibles par les développeurs. Il suffit de constater la popularité du projet Backstage, une brique reprise par Red Hat et WMware. Certains exploitent directement GitHub Actions pour exécuter des scripts additionnels, comme les Ops d’Air France.

D’autres comme Mercado Libre, un géant de l’e-commerce brésilien, ont conçu leur propre plateforme d’ingénierie. Celle de Mercado Libre, Fury, est utilisée par plus de 12 000 développeurs et permet de gérer plus de 24 000 microservices.

Selon HashiCorp, Waypoint s’adresserait davantage aux petites équipes d’ingénierie devant gérer des centaines, voire des milliers de composants. Pour autant, Waypoint n’est pour l’instant disponible que depuis l’offre cloud managée de l’éditeur. 

Or selon le retour d’un ingénieur cloud chez GM Financial, Jeremy Myers, l’intégration entre HCP Terraform et Waypoint n’est pas encore finalisée. Il n’est pas possible de vérifier les erreurs de planification sans devoir accéder directement à l’environnement HCP Terraform.

En parlant de planification, sur le papier, l’alignement entre Terraform Stacks, présenté comme le futur de HCP Terraform, qui ne s’appuie plus sur les espaces de travail (workspaces), et HCP Waypoint, qui en fait un grand usage, n’est pas clair. Ils ont toutefois en commun de s’appuyer sur les fameux modules.