FinOps : de précieux conseils pour réduire les coûts du cloud

Le cloud impose de nouvelles normes

« À part les DSI qui s’étaient positionnées comme des fournisseurs de services pour les métiers, le cloud a largement bouleversé le mode de paiement », constate Yann Carpentier-Gregson. « Nous sommes passés d’une gestion des coûts pluriannuelle, où l’on achetait sa baie de serveurs pendant trois ans pour l’amortir par la suite, à un modèle à la consommation. Désormais, il faut piloter les coûts IT comme les coûts de projets ou de prestations et les réintégrer dans le pilotage financier de la structure. C’est aussi une démarche de changement auprès du contrôle de gestion pour attribuer les lignes de budgets aux projets », estime-t-il.

La fondation FinOps a justement émergé pour aider les DSI à contrôler leurs dépenses auprès des fournisseurs.

« Nous avons étudié la documentation publiée par la fondation FinOps, mais ce n’est pas aussi abouti et public que les approches DevOps, DevSecOps et Agile », nuance Yann Carpentier-Gregson.

Sur les grands principes, le responsable n’a rien à redire. D’ailleurs, il s’aligne sur les affirmations d’Olivier Rafal, principal strategy consultant chez SFEIR, dans une tribune publiée dans les colonnes du MagIT.

De son côté, Yann Carpentier-Gregson veut rappeler les grandes différences entre une application de l’approche FinOps en amont et en aval d’un projet cloud.

« Si une entreprise démarre son projet cloud, il faut traiter la problématique FinOps sous l’angle de la gouvernance et du pilotage financier », conseille-t-il.

« L’important, c’est que pour chaque ressource, objet, service qu’elle déploie, l’organisation soit capable de répondre aux trois questions suivantes :

• Pour qui ? Afin d’avertir les référents et leur poser les bonnes questions.
• Qui paye ? Parce que ce n’est pas forcément les mêmes personnes.
• Et à quoi ça sert, pour quoi ? », ajoute-t-il.

De bonnes réponses à ces trois questions seraient les clés d’une administration économique réussie d’une plateforme cloud.

Mais l’approche FinOps est transverse, elle mêle aspect financier, métier et technique, selon Yann Carpentier-Gregson. « C’est d’ailleurs pour cette raison que ce sujet est avant tout porté par les architectes chez Umanis, car ce sont eux qui maîtrisent les arcanes des fournisseurs de cloud », indique-t-il.

« Nous devons être au contact des architectes pour adapter la technologie, et des métiers pour leur faire prendre conscience du coût réel de leurs cas d’usage. Nous avons tout de même un historique, en France, de séparation des coûts IT et des coûts business. Souvent, l’IT est perçue comme un pot commun qui revient trop cher, dans lequel chacun contribue sans forcément savoir véritablement à quoi ça sert. C’est une éducation à effectuer en parallèle de la gouvernance financière », considère le practice manager.

L’équipe de Yann Carpentier-Gregson met en pratique ces politiques de réduction de coûts en travaillant avec les équipes d’exploitations, et les développeurs, quand ceux-ci n’ont pas optimisé leur code. « Nous augmentons le niveau d’information des product owners pour que les arbitrages puissent être rendus entre l’accélération du développement, la gestion de la stabilité et l’optimisation des ressources. Enfin, au niveau DSI, nous aidons au contrôle de gestion, le conseil à l’achat en volume, la stratégie technologique choisie pour l’architecture de données, à la fois pour suivre les évolutions des services, mais aussi pour mutualiser certaines ressources quand cela est possible et réaliser des économies d’échelle ».

Le FinOps, le jeu des compromis

Car une gestion des ressources cloud et de manière plus générale IT, ne peut se limiter à une politique de coupe dans les coûts. « Il ne s’agit pas de s’assurer que les coûts sont minimes, mais d’être capable de “challenger” le ROI pour chaque usage : quel service rend-on et à quel prix ? On n’optimise pas les coûts, mais le rapport qualité-prix », nuance Yann Carpentier-Gregson. « La question à se poser est la suivante : est-ce tenable par rapport aux gains obtenus au travers du cas d’usage ? ».

Justement, les cas d’usage doivent en grande partie dicter le choix de l’architecture technique. « Cela ne peut pas être des choix effectués dans une tour d’ivoire parce que des décisions d’économie d’infrastructure peuvent avoir un impact explosif sur les coûts de développement ou sur la stabilité », alerte le responsable. « Il faut pouvoir dialoguer avec tout le monde et intégrer les problématiques de tous les acteurs à la table afin d’arbitrer en conséquence ».
Cet arbitrage multipartite est sans doute l’aspect le plus complexe d’une gestion FinOps en entreprise. Ici, la problématique est avant tout organisationnelle. « Souvent, la production est dans son coin, les développeurs dans le leur, les architectures dans leur tour d’ivoire et le contrôle de gestion a lieu une seule fois par an », déplore le practice manager.

Dans l’ère FinOps, le product owner, le responsable d’un projet joue désormais un rôle considérable. « C’est au product owner de valider les décisions. Si tout n’est pas parfait au moment de la mise en production, il doit choisir l’indicateur qu’il souhaite privilégier ou dégrader, temporairement ou non », déclare Yann Carpentier-Gregson.

Si la démarche consiste à favoriser l’usage, ce n’est que partie remise. « Dans certains cas, le coût de run d’infrastructure est déplorable, mais il est décidé de ne pas procéder à une optimisation pour des raisons métiers et de maintenabilité. La production est alors lancée en état, avec une prédiction financière précise. L’optimisation est alors planifiée au prochain sprint », note l’expert.

Par exemple, certaines entreprises choisissent délibérément de ne pas tirer le meilleur parti des dépenses de sécurité, d’infrastructure réseau, d’exposition du SI et des Ops, quand elles engagent leurs premières initiatives cloud.

« Le FinOps n’a rien de magique. C’est souvent une affaire de bon sens pour peu que l’on ait les bonnes raisons techniques ».

« Le FinOps n’a rien de magique », prévient notre interlocuteur. « C’est souvent une affaire de bon sens pour peu que l’on ait les bonnes raisons techniques. Cela concerne toute la DSI, pas seulement un sujet des Ops », ajoute-t-il.

« L’important n’est pas de faire mouche au premier coup, mais de savoir en combien de temps une erreur peut être corrigée. Tous les incidents ou surcoûts ne peuvent être évités », rappelle-t-il.

Le FinOps au quotidien

La gestion plus quotidienne du coût du cloud, l’aval donc, dépend souvent du volume de données, c’est-à-dire des espaces de stockage et des ressources CPU utilisés. « Selon les technologies employées, il y a différentes optimisations à effectuer afin de baisser la consommation de l’infrastructure. Il y a aussi des normes de développement différentes. Les traitements écrits en Python sollicitent moins la plateforme, que ce soit en termes de temps de calcul, qu’en termes d’accès I/O au stockage qui parfois est facturé. C’est de l’optimisation “grain fin” », déclare-t-il.

Mais avant d’en arriver là, il faut mettre en pratique les « classiques ». « Une des principales failles à éviter : les oublis. Par exemple, un développeur lance un traitement, part en week-end prolongé et oublie de l’éteindre au bon moment », illustre le spécialiste.

Il faut également éviter les « les tempêtes de données ». « Un traitement dont la capacité de calcul n’a pas été limitée et qui prend en compte toutes les nouvelles données est nocif. Nous avons déjà eu le cas avec un système Apache Kafka qui s’était emballé. Le temps d’appuyer sur le bouton pour l’arrêter, 10 000 euros s’étaient envolés », témoigne-t-il.

La réservation de ressources, une bonne technique de pilotage financier

S’il est difficile au départ de savoir le volume de ressources qu’un projet va consommer, il convient de lancer une deuxième phase d’optimisation après quelques mois, voire un an d’usage des infrastructures cloud.

« La deuxième phase consiste à consulter son fournisseur de cloud en lui présentant des inducteurs de longue durée et lui dire : “aujourd’hui, nous consommons tant de volumes, dans un an nous pensons en utiliser tant”. Cela permet de faire des réservations de ressources au volume pour ce qui est justifié », explique notre interlocuteur.

Si l’optimisation projet par projet dépend des products owners, l’attribution des services et des instances émane d’une compétence transverse, tenue par la DSI. En effet, la réservation de ressources dépend idéalement d’une commande groupée.

De fait, les fournisseurs de cloud pratiquent généralement des réductions au volume. AWS propose des « instances réservées » qui permettent par exemple d’économiser 72 % sur le prix des instances EC2. Microsoft Azure s’est aligné sur cette référence pour les machines virtuelles Linux et applique également des rabais sur les réservations pour différents services. Google Cloud fait de même avec les « remises sur engagement d’utilisation ».

Les éditeurs ont bien compris l’intérêt de cette possibilité, car ce sont généralement pour exécuter leurs produits que les entreprises consomment ces ressources cloud. La plupart du temps, ils proposent leurs logiciels sur les marketplaces des cloudistes, parfois avec certaines limites de consommation.

« Leurs solutions sont disponibles en paiement à la consommation, mais à un tarif catalogue grand public, sans réductions commerciales. Ensuite, les éditeurs ont une démarche d’accompagnement pour les grands comptes via la remontée d’informations vers leur CRM. La consommation pour des petits volumes est “gratuite” et certains d’entre eux vous contactent pour faire des rabais en proposant des services professionnels, des contrats de réservations, du coaching, etc. ».

Si des instances réservées sont associées au produit d’un éditeur, « les outils des plateformes permettent – je ne dirais pas simplement, parce que ce n’est pas vrai – de piloter la réservation ». En cas de dépassement, il est de bon ton de recontacter l’éditeur ou le fournisseur pour ajuster les plans de consommation, conseille Yann Carpentier-Gregson.

« Quand on analyse les économies à dégager in fine, cette politique du contrat unique est quelquefois mise à mal ».

« L’on peut aussi choisir de ne pas avoir d’attaches à un contrat ou tout faire passer par le contrat avec le fournisseur cloud. Quand on analyse les économies à dégager in fine, cette politique du contrat unique est quelquefois mise à mal », ajoute-t-il.

Mais le cloud évolue beaucoup plus rapidement qu’une infrastructure on premise. Cela demande de mettre en place une veille technique et tarifaire. Umanis a développé sa propre méthode. « Nous mettons en place des comités de gouvernance trimestrielle qui renseignent les changements techniques au sein des produits et les modifications de prix, et qui proposent des solutions pour y remédier. Nous imposons à nos clients une revue des coûts trimestriels. Cela demande une réorganisation, pour remplacer des actions qui sont souvent effectuées tous les deux à trois ans », témoigne notre interlocuteur.

En cela, faire appel à un prestataire externe est intéressant, selon le responsable. « En outre, nous sommes capables d’estimer les rabais que les clients peuvent obtenir auprès de leur fournisseur cloud », conclut-il.