Nous avons vu dans l’article précédent comment rentrer dans le cercle vertueux du FinOps, à travers la phase Informer. Cette phase permet de poser des bases saines sur lesquelles s’appuyer pour avancer. En ce sens, elle doit être réalisée avec soin, mais il ne faut pas pour autant attendre d’avoir un tableau de bord ultra complet et détaillé avant de passer à la suite. La pratique FinOps, au même titre que l’Agilité et le DevOps avec qui elle partage des valeurs communes, se veut avant tout itérative et rapide. Il faut donc chercher à passer dès que possible à la phase Optimiser pour constater les premiers effets bénéfiques de la pratique.
Les freins à cette transition, lorsqu’une entreprise débute dans le FinOps, sont notamment :
- Le manque d’adhésion : dans la phase Informer vous pouvez être perçu comme un oiseau de malheur qui met le doigt là où ça fait mal, ce qui ne galvanise pas les foules.
- La légitimité : vous êtes en contact avec des profils variés (techniques, business, finance…) et sauf à être aguerri dans tous les domaines, à un moment ou un autre vous donnerez sûrement l’impression de vous mêler de ce qui ne vous regarde pas. Une équipe FinOps pluridisciplinaire permet de lever ce frein.
- La dimension exploratoire : vous construisez quelque chose de nouveau, il se faut se tailler un chemin à travers la jungle de l’inertie, des processus, des agendas surchargés et surtout de l’inconnu.
Mais revenons à la définition : le dictionnaire nous dit que optimiser, c’est donner à quelque chose le rendement optimal en en tirant le meilleur parti possible. Cela résume bien la philosophie du FinOps, à savoir tirer le meilleur parti du Cloud afin d’obtenir le plus petit coût pour l’unité de production de l’entreprise. La notion de rendement est aussi intéressante car elle résonne fortement au sein des entreprises du numérique qui ont les yeux rivés sur le ratio coûts/bénéfices de leurs produits.
Si la phase Informer répond principalement à la question “quels sont les coûts ?”, il s’agit ici de répondre à “ces coûts sont-ils optimaux ?” et “comment optimiser ceux qui ne le sont pas ?”.
Faire du FinOps n’est pas tout le temps synonyme de réduction des coûts du Cloud, nous aurons l’occasion d’y revenir brièvement plus bas. Néanmoins, l’objectif principal de cet article sera d’exposer les moyens de réduire les coûts, et les considérations liées à l’unité économique feront l’objet d’un autre article.
La force du Cloud est sa flexibilité, c’est-à-dire que l’on peut provisionner et déprovisionner une ressource facilement selon nos besoins, avec un comptage à la seconde près pour les CSP (Cloud Service Provider) leaders du marché que sont GCP, Azure et AWS. Le montant de la facture à la fin du mois sera en grande partie dépendant de la formule P*Q, où P est le prix unitaire d’utilisation d’une ressource et Q la quantité de ressource utilisée. Il s’ensuit donc que si l’on veut diminuer la facture, on devra jouer sur l’un et/ou l’autre de ces deux éléments.
Le premier angle d’attaque : les prix
C’est la manière la plus rapide de commencer à faire du FinOps car on ne touche pas à l’architecture. On peut réaliser facilement et rapidement des premiers savings assez conséquents sans diminuer la consommation de ressources.
Le prix normal, ou prix public, d’une ressource est le plus élevé, et offre en contrepartie une flexibilité et une sécurité totale sur la ressource. Mais si vous êtes prêts à faire des compromis, voici quelques-uns des moyens disponibles pour faire baisser les prix.
Les réservations
Le plus connu des leviers sur les prix, mais aussi l’un des plus complexes, est la réservation. L’idée est de s’engager auprès du CSP à consommer une ressource précise sur une durée déterminée (en général 1 ou 3 ans), et en retour le CSP propose un tarif très avantageux.
La réservation est une sorte de crédit de consommation, payé à l’avance mensuellement selon les CSP, et qui a une date d’expiration. En utilisant à temps complet la ressource concernée, vous profitez pleinement de ce levier. En n’utilisant que partiellement la ressource, cela reste rentable jusqu’à un certain seuil d’utilisation en dessous duquel il faut éviter d’aller.
Passer le cap des réservations n’est pas anodin : on s’engage sur une, voire trois années, beaucoup de choses peuvent se passer sur ce laps de temps. Pour commencer, on peut viser un faible taux de couverture de réservation (= volume de ressources payées en réservation sur le volume total) et augmenter progressivement tout en mesurant et analysant l’utilisation des réservations pour bâtir une stratégie adéquate. Cette stratégie doit dans tous les cas être le fruit d’une réflexion commune entre les équipes. Si besoin, les CSP laissent une certaine marge de manœuvre pour convertir ou annuler une réservation.
Les offres et spécificités des CSP concernant les réservations sont légions, et l’on pourrait y consacrer un article à part entière.
Tier de stockage
Tous les gros CSP proposent une palette de services de stockage, les tiers, adaptés aux différents usages existants. Les besoins en termes de vitesse d’écriture/lecture, disponibilité ou encore durabilité de la donnée ne sont pas les mêmes selon que celle-ci soit utilisée quotidiennement pour des fonctions critiques ou si c’est une donnée de sauvegarde en fin de période de rétention. Il peut donc être judicieux de catégoriser les données par criticité et fréquence d’utilisation, et d’attribuer à chaque catégorie un tiers de stockage. Ce travail parfois laborieux doit être refait régulièrement, mais certains CSP proposent des services (payants) pour aider les entreprises.
Discounts sur les volumes
Il existe un mécanisme de réduction automatique du prix des ressources chez certains CSP, au-delà d’un certain seuil de consommation franchi. On distingue deux types de seuil :
- Un seuil en volume : il faut consommer une quantité suffisante de ressources en un temps donné (une heure par exemple)
- Un seuil en durée : il faut consommer une ressource durant suffisamment longtemps
Ce mécanisme s’arrête lorsque le seuil de consommation est franchi à la baisse, cela doit donc être pris en considération avant de mettre en œuvre une optimisation qui va réduire la quantité.
Remises et crédits négociés
Les CSP aiment les gros consommateurs, et les encouragent à consommer encore plus en récompensant leur fidélité. Cela peut se faire à travers des remises sur le prix public, ou par l’attribution de crédits de consommation. Ces avantages varient selon les situations et se négocient entre le CSP et l’entreprise, sur la base d’un engagement de dépenses Cloud.
Ressources spot
Les CSP ont d’énormes quantités de ressources, et toutes ne sont pas utilisées en continu. Afin de les valoriser au maximum, ils proposent aux consommateurs d’utiliser ces ressources à un prix très avantageux par rapport au prix public (jusqu’à de 80% de réduction). Le revers de la médaille est que le CSP est susceptible de récupérer ces ressources n’importe quand et presque instantanément à partir du moment où il en a besoin. Ce type de ressources est donc à exclure pour les environnements critiques, mais sera adapté pour des usages du type POC, batch, base de données distribuées, containers…
Consommer moins pour payer moins
Il est a priori plus difficile d’optimiser la quantité, car cela nécessite des échanges avec les autres parties prenantes pour comprendre les raisons techniques ou business qui expliquent pourquoi l’infrastructure est dimensionnée ainsi. En aucun cas une décision de modification ne doit être prise unilatéralement par l’équipe FinOps ! Il y a également une dimension psychologique : on touche à une mécanique en place qui fonctionne, alors faut-il vraiment prendre le risque d’en changer ? Bien entendu, une optimisation ne doit pas se faire au détriment de la performance globale de l’infrastructure.
Notons que lorsque l’on parle de quantité, il s’agit à la fois de volume (nombre de ressources) et de durée (temps d’utilisation).
Enfin, rappelons-nous que toutes les ressources provisionnées ont un coût, qu’elles soient utilisées ou non. Réduire l’usage du Cloud revient en grande partie à traquer les ressources qui ne sont pas ou mal utilisées, c’est justement ce que nous allons voir maintenant.
Ressources non utilisées
Il est tellement facile de créer des ressources dans le Cloud, manuellement ou automatiquement, que même avec une sensibilisation sur le sujet, il n’est pas rare que des ressources soient oubliées. On peut citer notamment des machines virtuelles plus nécessaires, des sauvegardes pour des machines virtuelles qui n’existent plus, des disques de stockage non utilisés, des répartiteurs de charge qui n’ont plus de charge à répartir…
Il convient de faire la chasse à ces ressources oubliées, pour lesquelles il n’y a pas de dilemme : on les supprime et on fait des économies.
Rightsizing
Le rightsizing consiste à vérifier qu’une ressource a des caractéristiques techniques qui conviennent à son utilisation. Elle est parfois sous-dimensionnée, auquel cas elle causera probablement un problème dans l’infrastructure et sera corrigée. En revanche, aucun signal ne nous avertit lorsqu’une ressource est sur-dimensionnée, et c’est là que le FinOps intervient.
Le rightsizing est typiquement utilisé pour les machines virtuelles, avec leurs caractéristiques CPU et RAM. L’analyse de l’utilisation au cours du temps de ces caractéristiques permettra de sélectionner des potentiels candidats au rightsizing. Il est important de prendre en compte dans cette analyse d’éventuels pics d’utilisation qui surviennent ponctuellement. Sinon, gare aux ralentissements ou au plantage une fois le changement effectué, pouvant causer des pertes financières conséquentes !
Workload management
Le workload management, c’est se poser la question de l’utilité qu’une ressource soit provisionnée à un instant T. De même que l’on éteint la lumière dans une pièce en la quittant, il paraît logique d’éteindre une ressource lorsque l’on n’en a plus besoin, même temporairement. C’est en effet tout l’intérêt du modèle d’utilisation du Cloud.
Un moyen simple de réaliser des économies rapidement de cette manière (quick win) est de commencer par se tourner vers les environnements de test et de développement. Ces environnements ne sont la plupart du temps utilisés que durant les heures de travail classiques qui ne représentent que 30% du temps d’une semaine complète.
Cela se révèle plus complexe et plus risqué pour les environnements de production, mais une discussion entre l’équipe FinOps et l’équipe technique peut aussi permettre d’identifier des périodes durant lesquelles des ressources ne sont réellement pas utilisées.
Scaling
Si les produits hébergés sur l’infrastructure le permettent, on peut considérer utiliser le scale out (agrandissement horizontal, on joue sur le nombre de ressources) ou le scale up (agrandissement vertical, on joue sur la taille des ressources) pour suivre des variations à la hausse ou à la baisse de l’utilisation de vos ressources. Ainsi on ne sera pas obligé d’être trop conservatif dans le dimensionnement de l’infrastructure. On choisira l’une ou l’autre des options selon la situation (variations plus ou moins fréquentes ou rapides, type de ressource concernée…). Pour que ce levier soit réellement exploitable, il faut l’automatiser un maximum, en paramétrant des seuils qui déclenchent les actions de scale out ou scale up sans intervention manuelle.
Nous avons vu différentes possibilités d’optimisation de l’utilisation du Cloud, tant sur les prix que sur les quantités. Mais une fois que l’on a identifié une piste, comment avancer ? Comment savoir si elle en vaut la peine ?
L’importance de documenter les optimisations
Lorsque l’on présente une recommandation d’optimisation aux autres parties prenantes, il faut faire apparaître clairement les éléments en faveur de sa mise en œuvre, et ceux qui pourraient au contraire la disqualifier. Ainsi, un raisonnement de type “business case” est une bonne base pour échanger avec les différentes équipes.
Il met dans la balance les bénéfices apportés (coûts évités ou diminués, effet positif sur le chiffre d’affaires…) et les coûts engendrés (build, run, perte de revenus…). Les bénéfices et coûts ne sont pas tous directement financiers, on peut penser par exemple à l’impact sur la qualité de service ou la compétitivité. Ainsi, on peut préférer augmenter significativement sa facture dans la perspective de gagner des parts de marché.
Attention à ne pas oublier les coûts liés à l’humain : que ce soit le coût direct de la main d’œuvre ou le coût indirect de l’indisponibilité du personnel qui réalise cette action et ne peut donc pas se concentrer sur autre chose de potentiellement plus intéressant financièrement.
Pense-bête : intégrer la durée de vie d’une application dans l’analyse. Il sera sans trop coûteux en termes de main d’œuvre d’agir sur l’infrastructure d’une application dont la fin de vie est proche.
A première vue cela peut sembler long et compliqué de réfléchir à tous ces aspects, mais heureusement dans beaucoup de situations ce n’est pas le cas. Pour résumer, le business case aidera à déterminer si on y gagne plus qu’on y perd, et au bout de combien de temps.
Baisser les prix et consommer moins : deux leviers incompatibles ?
Nous avons vu plus haut que l’une des manières de faire baisser les prix unitaires était de consommer plus (discounts, crédits) ou à tout le moins de s’engager sur un volume minimal (réservations). D’un autre côté, les optimisations sur la quantité vont faire réduire la consommation, et donc à première vue mettre en danger voire saboter les initiatives basées sur les prix. En réalité, c’est beaucoup plus nuancé.
Tout d’abord, il est clair que la stratégie de réservation et les optimisations d’usage ne doivent pas être réfléchies séparément. Il est préférable d’appliquer des réservations en premier lieu sur des ressources qui ont été optimisées en quantité. De plus, comme évoqué dans la partie sur les réservations, on n’achète pas d’un seul coup des réservations qui couvrent la totalité de notre consommation Cloud. On commence au contraire par un faible taux de couverture et on l’augmente petit à petit, en même temps que l’on optimise la quantité. Une gestion régulière des réservations permettra de repérer le moment où les deux leviers commencent à entrer en conflit. Enfin, même lorsque l’optimisation d’un environnement est maîtrisée, il est préférable de garder un matelas de ressources hors réservations pour gérer les impondérables.
Concernant les discounts et crédits, ce n’est pas forcément un problème non plus. Il faut garder à l’esprit que les optimisations d’usage visent à consommer moins pour faire la même chose. La marge dégagée pourra donc être utilisée pour faire plus, en finançant par exemple l’innovation et la croissance de l’entreprise.
Montrez ce que vous faites
On l’a vu plus haut, les effets de la pratique FinOps ne se matérialisent pas tous en économies directes – c’est même parfois le contraire. Cependant, même pour une recommandation qui a effectivement un impact positif sur la consommation, celui-ci ne sera pas tout le temps visible sur la facture. En effet, il peut être compensé par l’augmentation d’une ressource par ailleurs, ou encore être trop modeste par rapport au montant global de la facture (pour nuancer le terme “modeste”, rappelons-nous qu’une petite baisse de coût sur un mois donné devient une vraie économie lorsque l’on raisonne sur la durée).
Il est donc important pour l’équipe FinOps de tracer les savings qui ont été réalisés grâce à son travail – en collaboration avec les autres parties prenantes évidemment. Cette tâche sera facilitée si des mini-business cases sont réalisés.
En communiquant sur les savings réalisés, une équipe FinOps démontrera ainsi son utilité et son efficacité, ce qui sera d’une grande aide pour l’adoption de la démarche au sein de l’entreprise. La première petite victoire pour une nouvelle équipe ? L’autofinancement !
Et ensuite ?
Nous avons maintenant à disposition quelques outils pour faire baisser la facture. Grâce à ceux-ci, l’équipe FinOps peut identifier des pistes d’optimisation, les caractériser et amorcer un dialogue avec les autres parties prenantes pour choisir les plus pertinentes et les prioriser. La phase suivante, Opérer, est celle de l’action. La gouvernance est mise en place, et, au travers des processus de l’entreprise, les recommandations sont implémentées. Leur effet est mesuré et communiqué aux équipes pour permettre un ajustement si nécessaire.
Tout cela et les autres aspects de la phase Opérer feront l’objet d’un prochain billet, dans le cadre de la série d’articles traitant du cycle FinOps
