Les trois piliers d'une culture d'optimisation des coûts en entreprise — et un guide pas à pas pour la bâtir avec les produits DoiT.
Dans beaucoup d'entreprises, l'optimisation des coûts relève presque toujours de la réaction d'urgence : elle survient face à un événement extérieur, comme une facture qui fait paniquer l'équipe finance ou la nécessité de réduire le burn rate avant une levée de fonds.
Si cela vous parle, il est temps d'adopter une approche plus proactive à l'échelle de toute l'organisation. L'optimisation des coûts ne devrait pas reposer sur une seule personne. Chaque ingénieur et chaque utilisateur du cloud doit s'en sentir responsable.
Mais pour que vos utilisateurs cloud s'en préoccupent, vous devez instaurer un sentiment de responsabilité et d'appropriation des coûts cloud chez tous ces utilisateurs. Cela passe nécessairement par une prise de conscience de leurs coûts. Et cette prise de conscience n'est possible qu'avec une allocation des coûts bien menée — c'est-à-dire la cartographie des coûts cloud vers leurs responsables.
YouTube
Touchez pour réactiver le son
Erreur 153
Erreur de configuration du lecteur vidéo
Visitez YouTube pour rechercher d'autres vidéos
Quand les utilisateurs cloud connaissent leurs coûts, ils s'y intéressent davantage. Ils posent de meilleures questions sur le montant de leur facture cloud. Et ils peuvent agir de façon proactive : en intégrant la dimension coût dès la conception d'une fonctionnalité, ou en s'attaquant en amont à des dépenses qui dérivent doucement.
Voici les trois éléments fondamentaux pour bâtir une culture de la maîtrise des coûts dans votre entreprise, afin qu'elle devienne une démarche continue pour l'ensemble de vos utilisateurs cloud.
Astuce #1 — Alignez votre hiérarchie de ressources sur votre structure organisationnelle
Dans l'idéal, vos ressources cloud doivent être organisées de façon à refléter la structure réelle de votre entreprise. Les Folders Google Cloud ou les Organizational Units (OUs) AWS sont parfaits pour cela.
Ils permettent de séparer et de catégoriser les ressources entre les différents départements et équipes de votre organisation. À l'intérieur, vous trouverez des projets (Google Cloud) ou des comptes (AWS), chacun de vos workloads appartenant à un seul projet ou compte.
YouTube
Touchez pour réactiver le son
Erreur 153
Erreur de configuration du lecteur vidéo
Visitez YouTube pour rechercher d'autres vidéos
Sans cette structure, attendez-vous à des écueils : prolifération des ressources, difficultés d'attribution des coûts et complexité accrue de la gestion des accès.
Le concept n'a rien de neuf en programmation. La loi de Conway postule que la façon dont les équipes communiquent et s'organisent influence les produits ou systèmes qu'elles créent. De la même manière, dans le cloud, structurer ses ressources pour refléter l'organisation de l'entreprise rend la gestion et la collaboration nettement plus fluides.
Isolez vos workloads dans leurs propres comptes ou projets
Vous devez également veiller à isoler vos workloads dans leurs propres comptes AWS ou projets Google Cloud. Nous croisons souvent des clients qui ont tous leurs workloads dans un même compte ou projet, ou qui partagent un même projet ou compte entre plusieurs équipes.
Lorsque vous regroupez des workloads sans rapport dans un même compte ou projet, gérer les coûts et suivre l'usage devient un casse-tête.
YouTube
Touchez pour réactiver le son
Erreur 153
Erreur de configuration du lecteur vidéo
Visitez YouTube pour rechercher d'autres vidéos
Imaginez par exemple des ressources liées à deux applications différentes hébergées dans le même projet Google Cloud. En n'isolant pas vos ressources dans des projets ou comptes distincts, vous devenez excessivement dépendant d'une hygiène de tagging irréprochable (nous y reviendrons dans la prochaine astuce). Et à mesure que votre organisation grandit, cette approche ne fait qu'alourdir l'attribution des coûts.
Quand c'est possible, optez pour un seul workload par compte ou projet. Cela dit, lorsque vous avez de petits workloads aux périmètres similaires, vous pouvez les regrouper dans un même compte (voir l'illustration ci-dessous).
Là encore, l'idée n'a rien de nouveau pour un développeur. Isoler les workloads cloud dans des comptes ou projets distincts rejoint le principe de programmation du couplage faible (loose coupling), qui consiste à concevoir des composants indépendants interagissant entre eux avec un minimum de dépendances.
En cloisonnant les workloads dans des comptes ou projets distincts, vous créez des environnements indépendants, faiblement couplés. Les bénéfices vont au-delà d'une allocation des coûts plus simple : vous profitez aussi de fonctionnalités opérationnelles de sécurité intégrées, comme les structures de permissions et le rate-limiting.
Astuce #2 — Taguez ou labellisez vos ressources
Les tags (AWS, Azure) et les labels (Google Cloud) servent à associer des informations granulaires à vos ressources cloud.
Cas d'usage :
- Enrichissement de la facturation (ex. ajout d'un cost center à une ressource)
- Classification d'environnement ou d'application (ex. niveau de sécurité des données)
- Automatisation (ex. définition des plannings de redémarrage)
Sur ce premier cas d'usage, les tags et labels jouent un rôle clé dans l'allocation et le suivi des coûts.
Les tags vous permettent de classer vos ressources par environnement, équipe, etc., et de délimiter clairement leur utilisation au sein de chaque catégorie. Combinés à des comptes bien définis, ils facilitent la personnalisation du reporting par équipe ou par application, grâce à des filtres plus précis.
YouTube
Touchez pour réactiver le son
Erreur 153
Erreur de configuration du lecteur vidéo
Visitez YouTube pour rechercher d'autres vidéos
Bonnes pratiques pour taguer ses ressources cloud
En matière de tagging, on peut être tenté de définir une structure très détaillée, avec une multitude de tags à appliquer à chaque ressource. Aussi louable soit-il, ce niveau de granularité est irréaliste au démarrage. Nous recommandons de commencer petit, avec 2 ou 3 tags seulement, mais en étant très strict sur leur application.
Les trois tags absolument indispensables (selon nous) sont :
- Nom d'application (ex. app_name)
- Équipe (ex. team)
- Étape ou environnement (ex. env)
Les tags étant sensibles à la casse, nous recommandons d'adopter une convention de nommage, comme le snake case, pour éviter les doublons. Les noms peuvent bien sûr être adaptés à la culture de votre entreprise, mais ils doivent rester descriptifs et clairs. Ici, app_name désigne un microservice ou un workload, et env correspond à une étape de développement comme development, testing ou production.
Les valeurs des deux champs devraient idéalement provenir d'une liste relativement standardisée. Là encore, si vos utilisateurs taguent leurs ressources avec des variations de Website - Backend, l'analyse des données s'en trouvera compliquée.
Un cas concret où les tags vous aideront à mieux comprendre votre consommation cloud : un compte de ressources partagées dans lequel sont regroupées toutes les bases de données utilisées par plusieurs équipes. Pour chaque base, vous pouvez attribuer un tag ou un label déterminant quelle équipe doit être facturée pour son utilisation.
Nous approfondissons ce sujet dans notre article Resource Labeling Best Practices.
Astuce #3 — Mettez en place un reporting en temps réel et des alertes personnalisées
Définir une hiérarchie de ressources bien rangée et taguer ses ressources, c'est très bien. Mais sans reporting et alertes en temps réel pour mettre ces données segmentées entre les mains de vos utilisateurs cloud, à quoi bon ?
L'effet Prius
Dans Cloud FinOps, publié chez O'Reilly, les auteurs décrivent l'effet Prius : un parallèle entre l'impact du reporting temps réel sur la conscience des coûts chez les ingénieurs et le fait de conduire une Prius.
Au volant d'une Prius, vous disposez en temps réel d'informations sur votre consommation d'énergie et sur l'autonomie restante de votre batterie. Appuyez fort sur l'accélérateur, et vous voyez immédiatement la consommation grimper et l'autonomie chuter. Cette information peut vous inciter à conduire plus sobrement. Ou, si vous êtes pressé, vous déciderez peut-être qu'accélérer vaut bien d'épuiser la batterie plus vite.
Quoi que vous fassiez de cette information, l'essentiel est que vous prenez désormais une décision plus éclairée, avec des données dont vous ne disposiez pas auparavant.
Le reporting temps réel permet une prise de décision décentralisée et éclairée
Le reporting temps réel des coûts cloud, à l'image d'une Prius affichant l'impact de votre conduite sur l'autonomie, fournit des informations immédiates qui permettent aux utilisateurs cloud de prendre, en toute autonomie, des décisions éclairées sur les pans d'infrastructure dont ils ont la charge.
Et même si une bascule vers une plus grande conscience des coûts ne se fait pas du jour au lendemain, le reporting temps réel oriente progressivement les comportements vers des décisions plus efficientes.
Il doit prendre la forme de rapports de coûts et d'usage, de dashboards, de budgets et d'alertes personnalisées qui livrent à chaque utilisateur cloud des informations pertinentes pour lui. Autrement dit, tout rapport consulté par un utilisateur cloud doit être filtré (en combinant vos tags et les comptes pertinents) pour n'afficher que la consommation dont lui ou son équipe sont responsables.
Cultiver la maîtrise des coûts avec DoiT
Les organisations digital natives s'appuient sur le portefeuille de produits DoiT — et sur son réseau mondial d'expertise cloud en FinOps et en infrastructure — pour prendre des décisions éclairées sur leur usage du cloud.
Voici, étape par étape, comment de nombreux clients DoiT instaurent une culture de conscience des coûts et de responsabilité au sein de leurs Engineers.
Cartographiez vos coûts cloud selon vos catégories métier
La première étape de l'allocation des coûts consiste à définir les regroupements métier auxquels vous voulez attribuer ces coûts. Dans DoiT Cloud Intelligence™, cela se fait via les Attributions. Les Attributions vous aident à regrouper des ressources cloud et à organiser les coûts d'une manière qui reflète votre logique d'allocation.
Voici deux exemples d'utilisation des Attributions pour cartographier les coûts par catégorie métier.
Dans le premier, nous définissons les coûts d'une application en regroupant trois comptes AWS distincts.
Cartographie des coûts cloud d'une application hypothétique
Dans le second, nous définissons les coûts d'une équipe de product engineering (ici Team Bruteforce) comme étant toute ressource portant un Label team ou un Project Label dont la valeur est bruteforce.
Cartographie des coûts cloud d'une équipe d'engineering hypothétique
Créez du reporting et des dashboards en temps réel
Vous pouvez ensuite utiliser les Attributions dans les Reports — et à terme dans les Dashboards — pour filtrer la consommation propre à une équipe, un environnement, une application ou tout autre périmètre que vous aurez défini avec les Attributions.
Par exemple, ci-dessous, nous avons utilisé notre Attribution Application A comme filtre, en ventilant les coûts par service et en n'affichant que le top 10.
Un rapport de coûts cloud ventilant les coûts d'une application définie via les DoiT Attributions
Vous pouvez ensuite planifier l'envoi récurrent de ce rapport, actualisé, aux utilisateurs cloud concernés. Une manière simple de commencer à sensibiliser les équipes à leur impact sur les coûts cloud.
Planification de l'envoi récurrent d'un rapport de coûts cloud
Vous pouvez également créer un dashboard dédié à une équipe ou à une application, pour offrir aux utilisateurs cloud concernés une vue d'ensemble de leurs coûts. Ci-dessous, nous avons ajouté notre rapport Application A - Service Cost à un nouveau dashboard qui regroupera d'autres rapports liés à la consommation de cette application.
Ajout d'un rapport de coûts cloud d'une application à un dashboard regroupant d'autres rapports sur cette application.
Le dashboard ci-dessous illustre ce que vous pouvez créer pour votre équipe, en complément de la planification de rapports envoyés aux utilisateurs cloud concernés.
Dashboard regroupant des rapports de coûts cloud personnalisés autour d'une application spécifique
Alertes personnalisées et Anomaly Detection ciblée
Au-delà des rapports, des alertes envoyées au bon moment — pour signaler aux utilisateurs qu'un aspect de leurs dépenses cloud mérite un examen plus approfondi — contribuent aussi à renforcer la prise de conscience et la responsabilité.
Mettez en place des alertes granulaires sur les coûts cloud pour les parties prenantes
Les clients DoiT configurent par exemple des Alertes lorsqu'ils veulent que les parties prenantes soient informées de l'usage à un niveau plus granulaire.
Ci-dessous, nous avons configuré une alerte de coût ciblée sur notre Attribution Application A. Telle que paramétrée, elle nous notifiera dès que le coût pour servir un customer donné — défini en sélectionnant le tag customer dans le menu déroulant Evaluate for each — augmente de 25 % ou plus d'une semaine sur l'autre. Le menu Evaluate for each est très utile lorsque vous voulez évaluer séparément chaque instance d'une même dimension (par exemple chacun de vos namespaces K8s).
Une alerte qui nous notifie dès que le coût pour servir un customer — défini via le tag customer dans le menu déroulant Evaluate for each — augmente de 25 % ou plus d'une semaine sur l'autre
Mettez en place une Anomaly Detection ciblée
DoiT Anomaly Detection surveille en autonomie les pics de coûts et vous alerte dès qu'une dépense anormale est détectée, pour en limiter l'impact sur votre facture. Par défaut, l'outil traque les comportements anormaux pour chaque SKU, sur l'ensemble de vos comptes ou projets.
Exemple d'anomalie détectée pour le SKU DataTransfer-Out-Bytes d'AWS S3
Les systèmes de détection d'anomalies fournissent généralement des informations sur l'usage cloud de toute l'organisation. Mais cette approche large finit souvent par inonder les équipes de notifications sans rapport direct avec leurs activités.
Avec DoiT Anomaly Detection, vous pouvez abonner vos utilisateurs cloud à des alertes d'anomalie spécifiques aux coûts dont ils sont responsables, via les Attributions. La détection d'anomalies passe ainsi à un autre niveau : vos équipes peuvent affiner les alertes qu'elles reçoivent pour se concentrer uniquement sur les coûts cloud dont elles ont la charge.
Une fois une Attribution créée, il suffit d'activer Anomaly Detection pour celle-ci.
Activation d'Anomaly Detection pour les ressources cloud d'une application spécifique
Vous pouvez ensuite vous rendre dans les paramètres de notification des personnes responsables d'Application A et les abonner aux alertes liées à cette Attribution (ou les laisser le faire elles-mêmes).
Comment s'abonner aux alertes d'anomalie pour une Attribution spécifique
Instaurer une culture de la maîtrise des coûts dans votre entreprise ne se résume pas à demander à vos utilisateurs cloud de s'en préoccuper davantage. Il faut leur donner les données qui leur permettent de prendre conscience du coût de leur travail.
Et pour livrer les données les plus précises sur l'impact de chaque personne ou équipe sur la facture cloud, vous devez aligner votre hiérarchie de ressources sur votre structure organisationnelle, définir les tags adéquats et taguer vos ressources en conséquence. Mais la véritable force réside dans la combinaison de ces fondations avec des mécanismes de reporting et d'alerte en temps réel.
Vous pouvez accomplir ces deux étapes avec DoiT, d'abord en travaillant avec nos experts FinOps pour définir les tags à créer — si ce n'est pas déjà fait — et une hiérarchie de ressources cohérente avec la structure de votre entreprise.
Une fois ces bases posées, vous pouvez utiliser les produits DoiT pour fournir à vos utilisateurs cloud du reporting et des alertes pertinents en temps réel.
Si vous êtes déjà client DoiT, vous pouvez suivre dès maintenant la démarche décrite ci-dessus, étape par étape, dans DoiT Cloud Intelligence. Sinon, contactez-nous pour découvrir comment tirer parti des produits et services de conseil DoiT à n'importe quelle phase de votre parcours cloud.