L'angle mort du multicloud

Une fragmentation inhérente au territoire

Tout programme de gestion des coûts cloud, quelle que soit son échelle, finit par se heurter à la même réalité architecturale : les outils natifs de chaque fournisseur ne voient que leur propre plateforme. Les outils natifs d'AWS ne font pas ressortir les inefficacités d'Azure. Les outils natifs d'Azure ne font pas ressortir les inefficacités de GCP. Les recommandations que produit chaque outil sont ancrées dans l'économie propre à son fournisseur, formulées selon des termes qui correspondent à la stratégie de ce fournisseur : instances réservées, plans d'épargne, remises sur utilisation engagée, chacune avec sa propre logique, sa propre surface de rabais, son propre profil de dépendance.

Pour les entreprises dont le parc s'étend sur plusieurs fournisseurs, ce qui est le cas de la plupart d'entre elles à partir d'une certaine échelle, cela signifie que le portrait des coûts est fragmenté par nature. L'équipe FinOps doit assembler une vue composite en reliant trois tableaux de bord qui ne partagent pas le même schéma, trois files de recommandations qui ne partagent pas le même modèle de politiques, et trois chemins de remédiation qui ne partagent pas le même flux de travail. Cette vue composite est fonctionnelle, mais elle n'est pas unifiée. Et les inefficacités qui tombent entre les mailles du filet, celles qui ne sont visibles par aucun outil d'un seul fournisseur, sont celles qui ont le plus de chances de rester inexploitées.

Où se cachent les économies à plus fort effet de levier

Les économies que les outils mono-cloud parviennent à repérer sont réelles, mais elles sont limitées à ce qui est visible depuis la perspective d'un seul fournisseur. Les économies que les outils mono-cloud ne peuvent pas repérer sont souvent celles qui offrent le plus fort effet de levier dans le parc.

Le placement des charges de travail entre fournisseurs en est l'exemple le plus évident : une charge de travail exécutée chez un fournisseur pourrait coûter nettement moins cher à faire tourner chez un autre, mais aucun outil natif ne vous le dira. L'équilibrage du portefeuille d'engagements en est un autre : une entreprise surengagée chez un fournisseur et sous-engagée chez un autre laisse de la marge de rabais sur la table, et cette optimisation reste invisible pour tout outil propre à un seul fournisseur, car elle exige de voir les deux côtés du déséquilibre simultanément. La capacité redondante répartie entre fournisseurs, les chemins de sortie de données dupliqués, les architectures multirégions qui n'exigent pas réellement toutes les régions qu'elles couvrent : voilà les catégories de gaspillage qui prennent de l'ampleur précisément parce qu'aucun outil mono-cloud ne peut les voir.

La raison structurelle pour laquelle un fournisseur ne peut pas résoudre ce problème

Devant cette lacune, la tentation est de croire qu'un des grands fournisseurs cloud finira par bâtir cette vue inter-cloud. Ce ne sera pas le cas, et la raison tient à la structure même du marché plutôt qu'à une limite technique.

Les outils de coûts de chaque fournisseur sont conçus pour optimiser à l'intérieur de l'économie propre à ce fournisseur. Une vue inter-cloud véritablement neutre devrait pouvoir formuler des recommandations du type « déplacez cette charge de travail hors de notre plateforme », et aucune feuille de route produit d'un fournisseur ne donnera priorité à la construction d'un tel outil. La vue inter-cloud n'est pas une fonctionnalité que les grands fournisseurs finiront par combler; c'est un conflit d'intérêts inscrit dans leur modèle d'affaires même. La frontière d'optimisation du client et la surface de croissance du fournisseur pointent dans des directions opposées, et les outils reflètent les intérêts de ceux qui les ont conçus.

Ce qui signifie que l'optimisation des coûts inter-cloud, si elle doit se réaliser, doit venir d'un fournisseur dont l'économie n'est liée à la préservation d'aucun fournisseur en particulier. Les intérêts de la plateforme doivent s'aligner sur l'ensemble du parc du client, et non sur une seule tranche de celui-ci.

À quoi ressemble vraiment une remédiation unifiée

Le changement dont la catégorie a besoin, c'est une plateforme qui opère sur l'ensemble du parc à travers un seul et même prisme : 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 appartenant à un seul fournisseur.

C'est la couche dans laquelle Jetscale opère. AWS, Azure et GCP sont vus à travers la même instrumentation, régis par les mêmes politiques d'affaires, présentés dans le même flux de demandes de tirage (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 tel ou tel fournisseur. Les inefficacités inter-cloud qui tombent entre les mailles des outils natifs, placement des charges de travail, déséquilibre des engagements, capacité redondante, optimisation de la sortie de données, deviennent des objets à part entière dans un seul flux de travail plutôt que des angles morts répartis entre trois tableaux de bord.

La conséquence opérationnelle est importante. L'équipe FinOps cesse d'effectuer le travail manuel de rapprochement entre trois tableaux de bord natifs. L'équipe de plateforme cesse de maintenir trois chemins de remédiation distincts, chacun avec ses propres conventions de gestion du changement. Les recommandations qui remontent sont préfiltrées en fonction des politiques réelles et de la réalité opérationnelle du client, peu importe le fournisseur concerné. La vue composite devient une vue unifiée.

Une question qui relève de l'approvisionnement, pas seulement des outils

L'implication plus profonde, c'est que l'optimisation des coûts inter-cloud n'est pas d'abord une question d'outillage, mais une question qui relève de l'approvisionnement. La stratégie multicloud est en amont de l'optimisation des coûts : la décision d'opérer sur plusieurs fournisseurs répond habituellement à des impératifs de résilience, de rapport de force avec les fournisseurs, de géographie réglementaire ou d'adéquation des charges de travail. Quelle que soit la raison qui a motivé cette stratégie, elle appelle une couche d'optimisation qui lui corresponde. Une stratégie multicloud jumelée à des outils de coûts mono-cloud est une stratégie qui manque d'une composante porteuse.

Le cadre de l'approvisionnement clarifie aussi utilement le calcul entre bâtir et acheter. Assembler soi-même des outils natifs entre plusieurs fournisseurs est faisable à court terme, mais le fardeau de maintenance s'alourdit 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 les uns des autres. 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 en faveur de l'approche maison se détériore.

Dans un monde multicloud, les outils de coûts mono-cloud forment une catégorie en voie de disparition. Les plateformes qui définiront la prochaine décennie sont celles conçues pour le parc tel qu'il existe réellement : réparti entre plusieurs fournisseurs, régi par un seul modèle d'exploitation, optimisé par un seul flux de travail.