Quel avenir pour le FinOps ?

Quel avenir pour le FinOps ?

 

Culture, outils, compétences, bonnes pratiques… Aujourd’hui le grand et nouveau terrain de jeu de l’optimisation financière dans le monde du paiement à l’usage est parcouru de toutes parts : nouveaux acteurs et profils, frameworks, livres, formations, certifications…

Une FinOps Foundation a également vu le jour aux US en février de cette année (que ferait l’IT sans ses « foundations » ?) ainsi que le premier groupe Meetup Français sur le sujet, dont Timspirit a l’honneur d’être membre fondateur et qui vous attend par ailleurs nombreux !

La légitimité d’une maîtrise des coûts n’est évidemment pas à remettre en cause. Alors même que les DSI petites et grandes s’échinent à décliner aujourd’hui leur approche FinOps sur le terrain, que pourrait-on dire quant à son avenir si on relevait un peu la tête du guidon ?

 

Revenons-en d’abord à l’origine

 

L’optimisation et le contrôle des dépenses n’est pas apparu avec le Cloud, ni même le pay-per-use. Pourquoi alors ce terme et cette discipline s’affirment-t-ils autant depuis quelques années ?

Dans cet article, penchons-nous sur une des origines de FinOps. Dans cette égalité comptable pleine de bon sens, penchons-nous sur le premier membre de l’équation : l’utilisation des ressources IT.

 

 

Nous avons tous en tête ce genre de courbe, opposant sur-allocation des ressources (menant à un gaspillage) d’un côté et leur sous-allocation de l’autre (menant à une qualité dégradée).

 

 

Tout ceci met en évidence l’incapacité d’aligner à un instant T l’allocation des ressources à leur consommation effective. En somme, l’opposition entre contenant et contenu nécessite d’être activement gérée et prise en charge dans l’entreprise.

L’impact du Cloud Public, et en particulier de la généralisation du paiement à l’usage, donne un nouvel essor à la prise en charge de cette opposition contenant/contenu pour deux raisons principales :

  • Il en modifie la granularité. Les ressources IT déployées sont plus nombreuses, facilement manipulables et assemblables entre elles.
    On peut en somme leur attribuer les 4 propriétés de l’acronyme CRUD (Création de ressources, Mise à jour et Suppression de ressources, ainsi que la capacité constante à n’importe quel instant de connaitre leurs propriétés et leur statut), auparavant réservé à la gestion de données.
  • Il en améliore l’optimisation. Les gains sont visualisables en quasi-temps réel. L’inertie provenant des gros investissements en CAPEX et leur amortissement sur plusieurs années disparaissent.

 

Comparons par exemple la répartition des coûts entre un SI on-premise classique (Cloud Privé compris) et un SI Cloud de type IaaS avec paiement à l’usage :

 

Auparavant, les coûts très importants des équipements (bâtiments, énergie, matériel et maintenance…) engageaient l’entreprise sur plusieurs années et se devaient d’être renouvelés à intervalle régulier en mobilisant d’importants moyens humains (pilotage d’appel d’offre, expertise technique & légale, processus d’achat…). Les leviers, bien qu’existants, étaient quant à eux difficiles à manœuvrer : gains limités dont l’impact tardait à se manifester.

Aujourd’hui, ces investissements disparaissent. Le grand chantier du FinOps porte sur les ressources IaaS et leur utilisation à l’usage.

Actuellement, les outils FinOps du marché récoltent pour la plupart des métriques d’usage des ressources IT déployées et donnent des recommandations sur les changements à apporter. Le Right Sizing est roi : il s’agit de faire coller l’alloué au plus près du consommé.

Si on fait l’analogie avec des services AWS, voici l’évolution d’une infrastructure type :

 

 

Ajuster à l’usage les instances EC2, les volumes EBS et les bases RDS ne changent en soi rien à la dichotomie contenant/contenu. Nous ne sommes guère loin de la chasse au gaspillage que l’on peut également mener dans une infrastructure on-prem.

Les gains sont en revanche plus faciles à atteindre, plus rapides à obtenir et loin d’être négligeables : voilà ce qui change.

 

Évolution vers le Serverless

Disons-le sans tarder, il est fort probable que le Serverless mette fin complètement à cette opposition contenant/contenu. Dans ce nouveau paradigme, l’allocation des ressources progressera ou diminuera avec l’usage. Autrement dit, dans l’analogie du verre à moitié vide ou deux fois trop plein, le verre grandira au fur et à mesure du niveau d’eau.

Le FinOps au sens large (pratiques, compétences, culture, outils) devra s’adapter et migrer progressivement d’une orientation Ops/Infra vers une orientation Dev. Il s’agira avant tout d’efficience applicative et d’optimisation de code.

 

 

En prolongeant l’analogie avec AWS, le modèle de prix de services Serverless laisse déjà peu de place à la chasse au gaspillage de ressources inutilisées.
On en trouve encore des traces dans AWS Lambda (allocation des ressources, notamment la mémoire attribuée à la fonction – rendez-vous ici pour du FinOps dans Lambda) et AWS Aurora Serverless (allocation par tranche d’ACU, c’est-à-dire un combo Mémoire/Compute – voir par ailleurs cet excellent article) : il est donc encore possible de jouer sur des inducteurs de coûts liés à l’allocation de ressources.

Mais la tendance est clairement à la généralisation de la consommation à l’usage effectif et à l’abandon d’une allocation de ressources : nous paierons en GB, en IO, en durée d’exécution, en nombre de requêtes… ce que nos applications consommeront réellement.

 

Bienvenue au FinDev

Dans un monde hypothétique 100% Serverless et On-demand, FinOps deviendra donc une tâche d’optimisation de code dévolue aux équipes de développement. Sans doute avec des gains moindres, les savings étant plus limités et plus difficiles à obtenir.

 

 

Ces nouvelles pratiques FinOps, disons FinDev pour les différencier, devront alors évoluer ainsi que les outils. De nouveaux sujets prendront de l’importance, surtout à l’échelle :
• Quelles librairies pour une consommation optimale CPU et mémoire ?
• Faut-il consommer plus de CPU et moins de stockage ou inversement pour tel Use Case ?
• Quels formats de stockage adopter (exemple intéressant ici) ?

 

 

Conclusion

Mais rassurez-vous, ce monde hypothétique est loin d’exister et vous n’aurez pas le temps de vous ennuyer ! Le paysage IT restera encore et toujours très hétérogène : mix IaaS et Serverless, multicloud, offres PaaS et surtout SaaS dont la gestion financière diffère également.

D’autres critères peuvent -et doivent- également être pris en compte dans l’optimisation des dépenses :

  • Le profil des applications et leurs prédictibilités en termes de charge (24×7 vs Business hours, demande constante vs forte variabilité)
  • Les options d’achats avec Reserved Instances, AWS Saving Plans et autres Committed Use Discounts sur 1 ou 3 ans
  • Les options spécifiques aux services ou des engagements de résilience
  • Le lock-in

Les études financières, « Business Cases » et autres « Cost Evaluation », ont encore de beaux jours devant eux.

Antoine Lagier

Antoine Lagier

Consultant @ Timspirit – Equipe Cloud Antoine a réalisé pendant 9 ans des projets d’infrastructure sur des sujets de stockage, de virtualisation, de supervision ou d’ordonnancement. Technophile avéré, il s’est tourné il y a quelques années vers le conseil en Cloud Computing et transformation des DSI. Antoine est un passionné de lecture et de musique – il débarque régulièrement à la péniche avec sa guitare ! C’est également un féroce adversaire au babyfoot…

Partager

Partagez ce post avec votre réseau !

Shares