Les praticiens du FinOps et les équipes techniques doivent commencer à travailler plus étroitement ensemble afin d’intégrer le reporting financier à leurs architectures, à leurs taxonomies de marquage et d’étiquetage, ainsi qu’à leurs autres configurations. Lorsqu’ils le font, cela peut être très bénéfique pour l’entreprise. Dans le cas contraire, les conséquences peuvent être lourdes.
Voici une étude de cas qui illustre parfaitement cette nécessité :
Récemment, un grand client du secteur des services financiers rencontrait de sérieuses difficultés pour gérer ses dépenses cloud. Son premier problème était l’impossibilité totale de refacturer les coûts cloud aux différentes unités opérationnelles. Plus problématique encore, il ne disposait d’aucun moyen d’imputer les coûts aux produits ou aux clients, ce qui empêchait de calculer précisément la marge brute de chacun. L’entreprise comptait environ 25 comptes de facturation auprès de fournisseurs cloud, mais 80 % de ses dépenses étaient concentrées chez deux d’entre eux, sans pour autant avoir une bonne visibilité sur l’utilisation de cet argent.
De plus, ses coûts cloud augmentaient de manière disproportionnée par rapport à ses revenus, et elle soupçonnait fortement qu’un volume considérable de gaspillage alimentait cette tendance. Mais le manque de visibilité sur les dépenses l’empêchait d’identifier et d’éliminer ce gaspillage.
Nous avons commencé à travailler avec le client pour résoudre le problème. Le processus a débuté par l’identification des personnes adéquates, issues de différentes fonctions de l’entreprise, pour rejoindre l’équipe FinOps à temps partiel. Comme ses dépenses s’élevaient à 20 à 25 millions de dollars US par an, l’entreprise a réaffecté une personne de son équipe technique afin qu’elle soit affectée à 100 % au FinOps. Une fois l’équipe constituée, l’entreprise a commencé à analyser ses données.
Travailler avec l’équipe FinOps
Les pratiques FinOps reposant sur une segmentation exhaustive et précise des dépenses, nous nous sommes d’abord associés à leur équipe FinOps pour relever ce défi. Celle-ci a documenté les conventions de nommage des ressources et les valeurs de balise pouvant servir à « cartographier » les ressources vers les unités opérationnelles. Cette correspondance a été intégrée à une table de leur base de données qui, à l’aide de requêtes logiques « si-alors », leur a permis d’enrichir les données de facturation avec des informations de segmentation par activité et de générer des rapports.
À mesure que le travail avançait, l’équipe a pu imputer une part croissante de ses coûts aux unités opérationnelles, jusqu’à rencontrer un obstacle : certains services cloud étaient facturés comme des éléments uniques (en l’occurrence, des hôtes de calcul exécutant plusieurs conteneurs), alors qu’en réalité ces éléments servaient plusieurs clients et hébergeaient différents services. Les données de facturation ne permettaient pas d’identifier quelle proportion de ces ressources partagées correspondait à quels produits et services.
À moyen terme, la seule solution consistait à développer un rapport distinct utilisant une API du logiciel (Kubernetes) exécuté sur les instances de calcul. L’API leur permettait de suivre l’utilisation de conteneurs spécifiques sur chaque hôte de calcul. Il fallait ensuite choisir une métrique de performance pour définir la proportion des ressources d’un hôte consommée par les clients et les services. Parmi les options envisagées figuraient l’utilisation du processeur, la quantité de stockage utilisée, la quantité de mémoire réservée et la quantité de mémoire consommée.
Examiner le processus
La décision a été prise de retenir comme métrique la quantité de mémoire réservée par chaque conteneur. Ce choix était logique car, qu’un conteneur utilise ou non la totalité de la mémoire qui lui est allouée, cette allocation reste indisponible pour les autres conteneurs et peut donc être considérée comme « utilisée ».
Autrement dit, si les conteneurs du client X réservaient 10 % de la mémoire d’un hôte, 10 % du coût de cet hôte était « imputé » au client X. Le processus était efficace, mais posait plusieurs problèmes :
- Il imposait aux membres de l’équipe technique une lourde charge de reporting, qui les détournait de leurs responsabilités principales.
- L’exécution du rapport prenait du temps, ce qui retardait la production chaque mois d’un rapport complet sur les coûts.
- Les rapports générés par les équipes techniques devaient être combinés aux données fournies par l’infrastructure de gestion des coûts FinOps afin de produire les rapports de refacturation. Ce post-traitement privait les utilisateurs des outils de gestion des coûts de l’entreprise de toute visibilité en temps réel sur les montants refacturés. En théorie, ils pouvaient demander une copie du rapport final, mais les rapports n’étaient exécutés qu’une fois par mois à des fins de comptabilité et de finance.
Bien que la solution de contournement fondée sur l’API produise le rapport dont l’entreprise avait besoin, le processus n’était pas viable à long terme. L’équipe technique a informé l’équipe FinOps que la seule véritable « correction » consistait à restructurer les « espaces de noms » des workloads afin que les coûts puissent être imputés directement à partir des données de facturation.
Ce projet était toutefois suffisamment vaste pour devoir être intégré au cycle global de sprints de l’équipe technique, ce qui allait repousser d’autres projets d’ingénierie nécessaires. Les espaces de noms remaniés ont finalement été mis en œuvre deux mois après le début de l’utilisation de la solution de contournement fondée sur l’API, ce qui a résolu le problème.
Le bilan a finalement été positif. L’entreprise a pu segmenter ses dépenses et imputer les coûts aux clients, aux services et aux équipes d’ingénierie qui les gèrent. Cela lui a permis d’agir bien plus efficacement sur les initiatives d’optimisation, d’arrêter les workloads de production abandonnés et d’optimiser sa participation aux programmes de remises des fournisseurs, car elle pouvait recueillir auprès de chaque responsable des prévisions d’utilisation.
Le résultat ? Alors que leurs revenus continuaient de progresser au même rythme, leurs coûts de cloud public se sont stabilisés, avec pour résultat étonnant une économie cumulée de 9 millions de dollars US au cours de la première année, par rapport au montant que les tendances antérieures laissaient prévoir sur la même période.
Malgré ce résultat positif, l’entreprise n’a repris le contrôle de ses dépenses cloud qu’après des mois, voire des années, d’exploitation avec une visibilité si limitée que le gaspillage cumulé atteignait largement plusieurs millions.
En définitive, ce gaspillage aurait pu être évité si l’équipe technique avait intégré les exigences de reporting à ses architectures techniques. Elle avait pris en compte les mérites techniques de chaque nouvelle architecture et avait également intégré l’efficacité des coûts à ses décisions techniques. Ce qu’elle n’avait pas fait, c’était ajouter un « troisième pied » à ce tabouret : les exigences de reporting.
Bonne pratique pour concevoir des architectures adaptées au FinOps
À mesure que l’utilisation de technologies reposant sur des ressources partagées, comme la conteneurisation et les hôtes de bases de données partagés, etc., se développe, le besoin de « concevoir des architectures adaptées au FinOps » augmentera lui aussi. Les architectes de solutions doivent faire de la conception adaptée au FinOps une pratique standard en suivant les étapes suivantes :
Recueillir les besoins
Recueillir, pendant la phase d’architecture, les besoins en matière de reporting pour les nouveaux workloads auprès des différents consommateurs de rapports financiers de l’organisation. Dans le cas présenté ci-dessus, cette démarche aurait montré que les équipes financières auraient notamment eu besoin de mesurer les coûts par client et par service.
Fortes de ces informations, elles auraient pu établir dès le départ un schéma d’espaces de noms pour leurs workloads conteneurisés, offrant cette visibilité. Elles auraient également appris que les instances de démonstration et de preuve de concept devraient être balisées avec les clients concernés afin de pouvoir être supprimées lorsqu’elles ne seraient plus nécessaires.
Les architectes de solutions doivent d’abord éviter la même erreur en identifiant les différentes parties prenantes qui doivent exploiter les rapports sur les données de dépenses cloud, notamment la direction, les services financiers et comptables, les responsables produits et les équipes techniques. Ils doivent organiser avec ces personnes des ateliers de travail afin d’inventorier les rapports nécessaires. Il est important de centrer ces discussions sur les besoins en matière de reporting et de distinguer les rapports qui « pourraient être utiles » de ceux qui sont « indispensables ». Les efforts consacrés aux premiers doivent être subordonnés à ceux consacrés aux seconds.
Identifier les dimensions non techniques
Ils doivent ensuite identifier les dimensions non techniques de l’architecture qui permettront de répondre aux exigences de reporting. Ces dimensions peuvent inclure l’alignement d’organisateurs tels que les comptes de facturation AWS, les projets GCP ou les groupes de ressources Azure sur les besoins en matière de reporting. Il convient également de créer des taxonomies de marquage et d’étiquetage répondant à ces exigences lorsqu’elles sont préférables aux organisateurs de facturation.
Point essentiel : les taxonomies de marquage et d’étiquetage doivent toujours être « guidées par la demande », ce qui signifie qu’il ne faut créer que les valeurs de balise nécessaires aux rapports requis. La charge imposée aux équipes techniques par les exigences de marquage doit être réduite au minimum. En matière d’étiquetage, un vieil adage de la gestion s’applique : mesurer l’activité de l’entreprise a un coût ; à moins qu’une métrique ne modifie une décision métier, il ne faut pas la mesurer.
Recourir à l’automatisation
Chaque fois que cela est possible, il faut recourir à l’automatisation pour garantir l’intégrité de l’application des organisateurs de facturation (comptes de facturation, etc.) et du marquage/de l’étiquetage. Rien n’est pire qu’une couverture de marquage insuffisante ou qu’une absence de hiérarchie des organisateurs de facturation, si ce n’est un manque d’intégrité des données de facturation !
Une fois que des ressources se retrouvent dans les mauvais organisateurs de facturation ou que des valeurs de balise inexactes se répandent dans les données, il peut être extrêmement difficile de remédier à la situation.
Identifier les scénarios clés
Identifier les scénarios dans lesquels les exigences de reporting nécessitent de modifier l’utilisation même des technologies cloud. Ils se présentent le plus souvent lorsque des services partagés, tels que des workloads conteneurisés ou des hôtes de bases de données partagés, sont utilisés.
Réviser si nécessaire l’architecture de référence afin de garantir le respect des exigences de reporting.
À propos de l’auteur :
Rich Hoyer est Director of Customer FinOps chez SADA.