De 60 % à 100 % de visibilité : Jupiter reprend la main sur ses dépenses d'infrastructure avec DoiT

DataHub est le volet de Cloud Intelligence conçu précisément pour combler ce manque. Il récupère les données de coûts situées en dehors des fournisseurs cloud et les place au même endroit que la facture cloud. Les données arrivent par API ou import CSV, avec les dimensions et métriques définies par le client, si bien qu'une facture d'un fournisseur trop petit pour justifier une intégration native devient une source que la plateforme traite comme n'importe quelle autre : exploitable dans les rapports, et disponible pour les budgets, les alertes et les prévisions.

La capacité existait, mais ce que Jupiter a obtenu, c'est quelqu'un pour construire à ses côtés.

Satyam Gupta, accompagné des Forward Deployed Engineers (FDE) de DoiT, est parti de la manière dont les factures arrivent réellement, et non de la documentation API. Il a converti un vrai PDF de Jupiter au format DataHub, l'a ingéré et a construit le reporting et les alertes par-dessus, afin que l'équipe puisse voir le résultat final avant de s'engager. Les Forward Deployed Engineers de DoiT sont intervenus là où le travail dépassait la simple configuration, tandis que Jupiter testait la solution et définissait comment les données devaient être lues, et l'équipe de Satyam a automatisé le flux à partir de ces retours.

"Lors de l'intégration de DataHub, l'équipe DoiT a été très impliquée, au point de mettre en place pour nous le premier script et le premier pipeline d'ingestion." confie Kyle.

Ce qui a été livré colle aux habitudes de l'équipe finance. Les factures atterrissent dans un dossier Google Drive, le pipeline les analyse et les charge dans Cloud Intelligence aux côtés de la facturation des fournisseurs cloud. Jupiter a apporté quelques ajustements mineurs et l'a mis en production.

Jupiter aurait pu suivre lui-même les fournisseurs manquants, mais cela laisse les données de coûts à deux endroits, et une prévision ne peut porter que sur un seul. 60 % dans DoiT et le reste ailleurs : impossible de planifier sur cette base. Kyle avait déjà utilisé d'autres plateformes FinOps, et c'est là qu'il voit la différence.

"DoiT a vraiment su combler un manque que je n'avais pas vu comblé par certaines des plateformes FinOps que j'ai utilisées par le passé." Kyle Espinola, Responsable Platform Engineering, Jupiter

Jupiter est un agrégateur d'exchanges décentralisés sur Solana. Le rôle d'un agrégateur est de trouver la meilleure route pour un trade à travers une liquidité fragmentée, et Jupiter fournit l'intelligence de routage et l'infrastructure de lecture pour y parvenir. Il n'assure ni la garde des fonds ni l'intermédiation des transactions. Plusieurs verticales financières reposent désormais sur ce socle, et une série d'acquisitions au cours de l'année écoulée en a ajouté d'autres. Chacune est arrivée avec sa propre infrastructure — c'est ainsi qu'une entreprise construite principalement sur AWS exécute aussi des workloads sur Cloudflare Workers, Google Cloud et sur du bare metal.

Faire tourner l'ensemble est la mission du platform engineering. Kyle Espinola dirige cette équipe, qui a la charge du Site Reliability Engineering (SRE), de l'infrastructure, de l'automatisation des déploiements et du FinOps, et publie les golden paths que toutes les autres équipes suivent pour mettre un service en production et en assurer le bon fonctionnement. Son ambition pour la plateforme suit celle du produit : la super app que construit Jupiter doit reposer sur une seule plateforme, pas sur plusieurs assemblées bout à bout.

Jupiter alimente DataHub avec 26 fournisseurs externes — ses fournisseurs RPC, ClickHouse et Cloudflare entre autres — aux côtés de sa facturation AWS et Google Cloud. La part que Kyle décrivait autrefois comme représentant plus de 30 % de dépenses non suivies se trouve désormais dans le même système que tout le reste.

"Passer de 60 % à 100 % dans un seul système change tout, et DataHub est un excellent outil, flexible, qui nous permet vraiment de combler les manques tout en tirant parti de tout le reporting." déclare Kyle.

Le taux de couverture n'est pas le seul bénéfice. Les prévisions et l'analyse de l'usage historique portent sur l'ensemble du catalogue de fournisseurs plutôt que sur la seule part cloud — et c'est sur cette base que Jupiter planifie. Les budgets et les alertes couvrent des fournisseurs qui n'avaient aucun monitoring, si bien qu'une facture qui s'envole est signalée immédiatement plutôt que découverte plus tard. Le catalogage que décrivait Kyle — penser à enregistrer une facture avant que le chiffre ne se perde — relève désormais du pipeline et non plus d'une personne.

La couverture était le prérequis. La prochaine question, c'est la rentabilité.

"Nous avons une visibilité très claire sur les revenus qu'un produit génère, mais pour comprendre la rentabilité, il faut connaître les coûts. Et une grande partie de nos coûts produits tient aux dépenses d'infrastructure." confie Kyle.

Les allocations vont rattacher ces dépenses aux lignes de produits à travers les fournisseurs, et Kubernetes Intelligence, activé ce trimestre, décomposera le parc Elastic Kubernetes Service (EKS) partagé par namespace. DoiT et AWS mènent la consolidation en parallèle, en négociant les accords contractuels et les crédits de migration pour faire migrer les workloads issus des acquisitions vers AWS.