Toute organisation qui a fait grandir son empreinte cloud finit par vivre la même réunion : la finance présente un graphique de dépenses en hausse, un outil FinOps est acquis, la discipline de balisage est resserrée, et les ressources inactives sont éteintes. Les coûts baissent brièvement puis reprennent leur ascension, parce que l'outillage a traité le gaspillage, pas la conception. Le gaspillage n'est que la plus petite part de la plupart des problèmes de coût cloud.
La part la plus importante est architecturale, et elle a été décidée bien avant l'arrivée de la première facture : où résident les données par rapport à l'endroit où elles sont traitées, à quel point les services sont couplés entre eux, et si les charges de travail partagent efficacement l'infrastructure ou portent chacune une empreinte dédiée et sous-utilisée. Rien de tout cela n'apparaît sur un tableau de bord de coûts, et rien de tout cela ne se corrige par une équipe finance agissant seule.
La gravité des données dicte la facture
Les données ont une gravité : plus elles s'accumulent en un lieu, plus il devient coûteux et gênant de les déplacer, et plus d'autres services sont conçus pour se situer près d'elles plutôt que de les déplacer. C'est efficace à court terme et coûteux à long terme, car cela fige les décisions d'architecture autour de l'emplacement historique des données plutôt que de la forme actuelle de la charge de travail.
Les frais de transfert de données entre régions et entre clouds figurent parmi les postes de coûts les plus persistants et les moins visibles d'un parc cloud, précisément parce qu'ils sont l'effet secondaire d'une ancienne décision de placement des données plutôt qu'une ligne budgétaire choisie activement. Revoir où résident réellement les données, et pourquoi, est une première étape plus productive que de resserrer la politique de balisage.
Un tableau de bord FinOps vous dit combien coûte une chose. Il ne vous dit pas pourquoi, et le pourquoi est une question d'architecture.
Le couplage transforme l'architecture en coût
Des services fortement couplés ont tendance à monter en charge ensemble même lorsque leurs schémas de demande réels n'ont aucun lien, ce qui signifie payer une capacité de pointe sur tout un ensemble de services pour satisfaire la demande d'un seul. Des services faiblement couplés, capables de monter en charge indépendamment, coûtent moins cher précisément parce qu'ils laissent le coût suivre la demande plutôt que le voisin le plus sollicité.
C'est pourquoi les efforts d'optimisation des coûts qui s'arrêtent à la couche infrastructure plafonnent rapidement. Redimensionner une instance ou négocier un meilleur tarif réservé fait économiser un montant fixe, une fois. Découpler un système pour qu'il monte en charge selon ses propres termes fait économiser un montant cumulatif aussi longtemps que le système existe.
- ·Cartographier où résident réellement les données par rapport à où elles sont traitées
- ·Identifier quels services montent en charge ensemble sans que ce soit nécessaire
- ·Revoir la mutualisation : infrastructure partagée contre empreinte dédiée sous-utilisée
- ·Traiter les tableaux de bord FinOps comme un suivi de symptômes, pas une solution
Les choix de mutualisation sont des choix de coût
Les architectures multi-locataires répartissent le coût d'infrastructure entre de nombreuses charges de travail ou clients et coûtent généralement moins par unité de travail. Les architectures mono-locataire, souvent choisies pour des raisons réelles d'isolation, de conformité ou de préférence client, coûtent plus par unité, et cette prime n'est défendable que lorsque la raison en est délibérée et comprise, non héritée d'une décision ancienne que personne n'a revisitée.
Les organisations ayant la meilleure discipline de coûts ne sont pas celles au processus FinOps le plus rigoureux. Ce sont celles qui revisitent les décisions de mutualisation et de couplage selon un rythme régulier, en les traitant comme des choix architecturaux vivants plutôt que des faits établis lors de la construction initiale.
Rien de tout cela ne plaide contre la discipline FinOps, l'hygiène de balisage ou les exercices de redimensionnement. Ils sont nécessaires et constituent la partie facile. La conversation plus difficile et plus utile est celle qui réunit architectes et finance dans la même pièce pour se demander pourquoi le parc a la forme qu'il a, et si cette forme correspond toujours à la charge de travail qu'il sert aujourd'hui.
Un coût véritablement maîtrisé ressemble moins à une revue mensuelle de tableur qu'à un comité de revue d'architecture doté d'un mandat de coût. Les organisations qui construisent cette habitude cessent de courir après la facture après coup et commencent à la façonner avant qu'elle n'arrive.