Que faire pour éviter que ma facture Cloud ne s’envole ?

Temps de lecture : 5 minutes

Faciles à consommer, accessibles de n’importe où, élastiques… les principaux avantages des services Cloud font aussi que la facture peut vite monter s’ils ne sont pas maîtrisés. Dans cette série d’articles, nous verrons les bonnes pratiques pour optimiser sa consommation, et les enjeux de la mise en place d’une culture FinOps dans le cadre de la transformation Cloud de l’entreprise.

Les montants de la facture des fournisseurs de cloud public deviennent maintenant significatifs par rapport au budget des DSI dans les grandes entreprises :

… et représentent la part majoritaire des budgets des startups qui sont nées avec le cloud. Selon le “Rightscale 2019 State of Cloud Report”, c’est maintenant le challenge majeur des utilisateurs du cloud…

…  qui ont de plus en plus de mal à contrôler ce budget.

Pourquoi les coûts sont-ils difficile à contrôler ? Essentiellement de par les caractéristiques du cloud (tels que définis par le NIST) :

  • Les services sont faciles à consommer (“on demand self services”): construire un POC (Proof of Concept) se fait en quelques minutes… On peut même profiter de configurations en capacité qu’on ne pouvait pas se payer dans le datacenter….
  • Les services sont accessibles de n’importe où (“broadband access”) : cela me permet de partager des environnements avec des partenaires ou des sous-traitants ou d’y accéder facilement à partir de chez moi (potentiellement donc en dehors du réseau de l’entreprise),
  • Les services sont élastiques (“rapid elasticity”): on peut faire évoluer leur capacité de manière simple et souvent sans arrêt de services

Ces caractéristiques expliquent des évolutions rapides et pas toujours maîtrisées de la consommation.

En contrepartie, 

  • Activer un environnement de POC uniquement quand on en a besoin n’est pas forcément naturel,
  • Optimiser les flux entre les composants dans le cloud public et les composants dans le datacenter nécessite d’urbaniser ses déploiements (les flux sortants (egress) du cloud sont facturés par les fournisseurs de cloud. Par exemple, si vous voulez traiter les logs d’audit cloud (Cloudtrail pour AWS) avec vos outils de SIEM (Security Information and Event Management) qui sont dans vos datacenters, prévoyez le budget pour couvrir ces flux.),
  • Identifier le bon type d’instance par rapport à un “workload” ou définir une architecture auto-scalable en fonction de l’utilisation nécessite de bien comprendre les principes d’architecture dans le cloud.

FinOps , la Solution ?

Pour adresser l’optimisation des coûts du cloud public, le buzzword c’est FinOps : l’alter ego du DevOps qui est parfois utilisé comme une approche, un rôle ou une organisation. On veut dire par là qu’il est nécessaire de faire dialoguer les FINanciers qui établissent les budgets et règlent les factures avec les OPS qui comprennent les services et la variation des capacités utilisées.

La Fondation FinOps a essayé de définir plus précisément ce terme :

FinOps is the operating model for the cloud. FinOps enables a shift — a combination of systems, best practices and culture — to increase an organization’s ability to understand cloud costs and make tradeoffs. In the same way that DevOps revolutionized development by breaking down silos and increasing agility, FinOps increases the business value of cloud by bringing together technology, business and finance professionals with a new set of processes.

Une traduction résumée permet d’indiquer que ce sont : des outils, des bonnes pratiques et une culture qui permettent de comprendre les coûts cloud et de faire les bonnes optimisations. Ces outils, bonnes pratiques et culture doivent être partagés par des interlocuteurs de différentes entités :

  • Le métier (BIZ) qui comprend la valeur de l’application pour l’entreprise et les usages prévisibles
  • Les architectes applicatifs et techniques (DEV) qui vont concevoir l’architecture applicatives et les services clouds qui vont la supporter,
  • Les opérations (OPS) qui vont visualiser les usages effectifs des capacités des services en fonction des usages de l’application
  • Les financiers (FIN) qui vont enregistrer les budgets, recevoir des factures mensuelles variables avec un détail par services, analyser l’évolution des coûts, déclencher le paiement fournisseur et facturer (Chargeback) ou rendre visibles les coûts (Showback) aux métiers.

Le FinOps est donc un FinDevBizOps qui s’ignore !

La compréhension et l’optimisation des coûts passe par le partage des informations entre ces différents interlocuteurs. Le cadre de référence du DEVOPS : CALMS (Collaboration, Automation, Lean, Measurement & Sharing) s’applique également directement au FinOps :

  • Collaboration : entre les différents interlocuteurs pour réaliser l’analyse des coûts par rapport aux usages et définir les axes d’optimisation
  • Automation : automatisation des analyses (regroupement des coûts en utilisant des tags : applications, domaines métiers, propriétaire métier, …), automatisation pour ajuster les capacités aux usages (démarrage des environnements quand ils sont utilisés, architectures auto-scalables et serverless), identification automatisée de “ressources zombies”,…
  • Lean : appliquer les principes du Lean pour réduire les “gaspillages” : le management visuel peut en langage financier s’appeler “showback” par exemple (Le principe du Visual Management dans le lean est de rendre visible des mesures relatives à l’activité que l’on souhaite optimiser. De la même manière, le principe du “showback” est de rendre visible les coûts aux acteurs qui les génèrent : ainsi une bonne pratique est de rendre visible le coût des environnements de développement et de test aux chefs de projet et architectes des équipes de développement afin qu’ils mesurent, par exemple, l’impact de maintenir un environnement de test actif en 24×7)
  • Measurement : développer les rapports de suivi des capacités utilisées en fonction des indicateurs métiers (avec CloudWatch sur AWS), analyser les coûts par services, par environnements et par application
  • Sharing : le partage des informations va faciliter la compréhension des coûts et la prise de décision afin de les optimiser

En conclusion de cette première partie destinée à faciliter la compréhension du FinOps , la première étape consiste donc à identifier les parties prenantes FinOps dans l’entreprise et ancrer la culture de l’optimisation des coûts entre ces différents acteurs. 

Dans les parties suivantes, nous allons détailler :

Commentaires :

A lire également sur le sujet :