Optimisation Cloud
Pourquoi les outils de coûts natifs des fournisseurs sont structurellement mononuagiques — et pourquoi les optimisations qui se glissent entre les mailles sont celles qui risquent le plus de rester non captées.
Tout programme de coûts infonuagiques d'une certaine envergure se heurte tôt ou tard à la même réalité architecturale : les outils natifs des fournisseurs ne voient chacun que leur propre plateforme. L'outillage natif d'AWS ne fait pas remonter les inefficacités d'Azure. L'outillage natif d'Azure ne fait pas remonter les inefficacités de GCP. Les recommandations que chaque outil produit sont ancrées dans l'économie de son fournisseur, formulées dans des termes qui conviennent à la stratégie de ce fournisseur — Reserved Instances, Savings Plans, Committed Use Discounts, chacun avec sa propre logique, sa propre surface de rabais, son propre profil de verrouillage.
Pour les entreprises ayant des parcs répartis sur plusieurs fournisseurs — c'est-à-dire la plupart d'entre elles à toute échelle significative — cela signifie que le portrait des coûts est fragmenté par conception. L'équipe FinOps assemble une vue composite en cousant ensemble trois tableaux de bord qui ne partagent pas de schéma, trois files de recommandations qui ne partagent pas de modèle de politiques et trois chemins de remédiation qui ne partagent pas de flux de travail. Le composite est fonctionnel; il n'est pas unifié. Et les inefficacités qui se glissent entre les mailles — celles qui ne sont visibles par l'outil d'aucun fournisseur pris isolément — sont celles qui risquent le plus de rester non captées.
Les économies que l'outillage mononuagique peut identifier sont réelles, mais elles sont bornées par ce qui est visible depuis la perspective d'un seul fournisseur. Les économies que l'outillage mononuagique ne peut pas identifier sont souvent celles à plus fort effet de levier dans le parc.
Le placement de charges de travail entre nuages en est l'exemple évident : une charge de travail exécutée chez un fournisseur peut être nettement moins coûteuse à exécuter chez un autre, mais l'outillage natif d'aucun des deux fournisseurs ne vous le dira. L'équilibrage du portefeuille de commitments en est un autre — une entreprise sur-engagée chez un fournisseur et sous-engagée chez un autre laisse de la marge de rabais sur la table, et l'optimisation est invisible pour tout outil mononuagique parce qu'elle exige de voir les deux côtés du déséquilibre simultanément. La capacité redondante entre fournisseurs, les chemins de data egress dupliqués, les architectures multirégions qui ne nécessitent pas réellement toutes les régions qu'elles couvrent — ce sont les catégories de gaspillage qui croissent précisément parce qu'aucun outil mononuagique ne peut les voir.
La tentation, devant cet écart, est de présumer que l'un des hyperscalers finira par bâtir la vue multinuagique. Ils ne le feront pas, et la raison est structurelle plutôt que technique.
L'outillage de coûts de chaque fournisseur est bâti pour optimiser à l'intérieur de l'économie de ce fournisseur. Une vue multinuagique réellement neutre devrait faire remonter des recommandations du genre « déplacez cette charge de travail hors de notre plateforme » — et aucune feuille de route produit d'un fournisseur ne priorisera de bâtir cela. La vue multinuagique n'est pas une lacune fonctionnelle que les hyperscalers combleront; c'est un conflit d'intérêts inscrit dans le modèle d'affaires. La frontière d'optimisation du client et la surface de croissance du fournisseur pointent dans des directions opposées, et l'outillage reflète les intérêts de ceux qui l'ont bâti.
Ce qui signifie que l'optimisation des coûts multinuagiques, si elle doit se produire, doit venir d'un fournisseur dont l'économie n'est pas liée à la préservation d'un fournisseur unique. Les intérêts de la plateforme doivent s'aligner sur le parc complet du client, et non sur une seule de ses tranches.
Le virage dont la catégorie a besoin, c'est une plateforme qui opère sur le parc complet à travers une seule lentille — un seul flux de travail, un seul modèle de politiques, un seul pipeline Git, un seul ensemble de recommandations ancrées dans l'infrastructure complète du client plutôt que dans la tranche d'un seul fournisseur.
C'est le palier où opère JetScale. AWS, Azure et GCP sont vus à travers la même instrumentation, gouvernés par les mêmes politiques d'affaires, acheminés vers le même flux de travail de PR. Les recommandations sont produites en fonction de ce qui est viable pour l'environnement du client dans son ensemble, et non de ce qui est stratégique pour un seul fournisseur. Les inefficacités multinuagiques qui se glissent entre les mailles de l'outillage natif — placement de charges de travail, déséquilibre de commitments, capacité redondante, optimisation d'egress — deviennent des objets de premier ordre dans un seul flux de travail plutôt que des angles morts entre trois tableaux de bord.
La conséquence opérationnelle est importante. L'équipe FinOps cesse de faire le travail manuel de réconciliation consistant à comparer trois tableaux de bord natifs les uns aux autres. L'équipe de plateforme cesse de maintenir trois chemins de remédiation distincts avec trois conventions de gestion du changement différentes. Les recommandations qui font surface sont préfiltrées par rapport aux politiques réelles et à la réalité opérationnelle du client, peu importe le fournisseur qu'elles touchent. La vue composite devient unifiée.
L'implication plus profonde, c'est que l'optimisation des coûts multinuagiques n'est pas une question d'outillage — c'en est une d'approvisionnement. La stratégie multinuagique est en amont de l'optimisation des coûts : la décision d'opérer sur plusieurs fournisseurs est habituellement prise pour des raisons de résilience, de levier face aux fournisseurs, de géographie réglementaire ou d'adéquation des charges de travail. Quoi qu'ait motivé la stratégie, elle implique un palier d'optimisation qui la reflète. Une stratégie multinuagique jumelée à un outillage de coûts mononuagique est une stratégie à laquelle manque une composante porteuse.
Le cadrage par l'approvisionnement clarifie aussi le calcul construire-ou-acheter de façon utile. Coudre ensemble l'outillage natif de plusieurs fournisseurs est réalisable à court terme, mais le fardeau de maintenance s'aggrave trimestre après trimestre à mesure que les API, les modèles de tarification et les schémas de recommandation de chaque fournisseur évoluent indépendamment. Une plateforme unifiée absorbe cette dérive pour le compte du client. Plus le parc opère longtemps sur plusieurs fournisseurs, plus le calcul de l'approche maison se détériore.
Dans un monde multinuagique, les outils de coûts mononuagiques sont une catégorie en voie d'obsolescence. Les plateformes qui définiront la prochaine décennie sont celles architecturées pour le parc tel qu'il existe réellement — réparti sur plusieurs fournisseurs, gouverné par un seul modèle opérationnel, optimisé à travers un seul flux de travail.
