Les erreurs classiques du FinOps

< Meilleures pratiques Finops

Trois grandes familles d’erreurs classiques liées au FinOps

La démarche FinOps a été conçue par des praticiens du Cloud, qui ressentaient le besoin de formaliser leurs pratiques empiriques. Il s’agissait de construire un cadre pour qu’eux-mêmes et les futurs praticiens ne commettent pas d’erreurs que d’autres auraient déjà expérimentées. Ces erreurs classiques peuvent se regrouper en 3 grandes familles.

Les erreurs méthodologiques

Les différentes étapes du cycle FinOps ne sont certes pas à suivre à la lettre, dans le même ordre et avec le même degré d’exigence et de profondeur par toutes les entreprises. Néanmoins, des invariants demeurent. Ne pas les respecter expose à prendre du retard dans la démarche, avec les conséquences que cela suppose sur l’efficacité du processus et la facture finale. Voici quelques erreurs classiques à éviter :

• Espérer économiser de l’argent grâce au Cloud et au FinOps en se contentant d’un “lift & shift” basique : sans un minimum d’adaptation aux spécificités du Cloud, les applications traditionnelles risquent même de coûter plus cher dans le Cloud que dans le datacenter ‘on premises’ de l’entreprise.
• Être trop ambitieux d’emblée : la démarche FinOps implique un changement culturel au sein des équipes et doit donc être le fruit d’une transformation progressive, par étapes.
• Attendre d’avoir évalué et affiné le dimensionnement de toutes ses ressources avant de procéder à des réservations de capacité : ces deux pratiques se répètent en continu et doivent donc être menées en parallèle.

Les erreurs de réservation

Réserver des ressources n’est pas si simple : il faut être sûr que ces ressources seront bien utilisées par les équipes DevOps sur la période concernée, faute de quoi l’objectif de réaliser des économies en achetant à prix discount des ressources se retournerait contre l’entreprise et deviendrait une dépense inutile. Voici les erreurs les plus classiques :

• Laisser les équipes DevOps gérer leurs réservations : c’est une tâche qui doit être centralisée au niveau d’un responsable FinOps, afin d’éviter les doublons de réservation, de négocier le cas échéant les meilleurs tarifs et d’assurer une gouvernance centralisée de l’ensemble des réservations.
• Acheter trop ou trop peu : cela paraît évident, mais il faut une bonne analyse du taux d’utilisation des ressources pour parvenir à déterminer le bon dimensionnement de réservation à effectuer. Il est donc recommandé de procéder par petits pas et souvent.
• Ne pas répercuter les coûts : si le coût des réservations n’est pas amorti sur la période d’utilisation des ressources, les équipes DevOps auront un faux sentiment d’économie sur l’usage des ressources réservées.

Les erreurs de redimensionnement

Attribuer aux services applicatifs un juste dimensionnement des ressources est crucial dans le cadre de la démarche FinOps, pour éviter de gaspiller des ressources. Certaines erreurs classiques peuvent toutefois aboutir à des effets contraires à ceux recherchés :

• Se baser sur la moyenne d’utilisation d’une ressource plutôt que sur l’usage en pic : cela risque de nuire gravement aux performances de l’application lors du pic d’utilisation si c’est mis en œuvre, ou de nuire à la crédibilité du responsable FinOps si les ingénieurs responsables de l’application décident de ne pas appliquer ses recommandations.
• Ne redimensionner que l’instance “compute” : les autres composantes du Cloud (base de données, stockage, réseau) sont aussi de potentielles sources d’économies.
• Ne pas réaliser de simulation des performances au préalable : vérifier l’impact potentiel des changements recommandés est essentiel pour ne pas trop réduire (ce qui nuirait aux performances) ni pas assez (ce qui ne serait pas très rentable).

Liens intéressants

• Pourquoi parle-t-on de cycle FinOps ?
• Quel est le vocabulaire du FinOps ?
• Quelles sont les meilleures pratiques FinOps ?