Comment maîtriser l’évolution de sa facture Cloud au-delà de la mise en place de bonnes pratiques ? Après avoir vu dans les articles précédents les grandes lignes du FinOps, les parties prenantes du FinOps dans l’entreprise, et les modèles de facturation des fournisseurs Cloud, nous abordons aujourd’hui le cycle de vie financier des applications Cloud.

La figure suivant présente le cycle de vie d’une application cloud depuis son architecture et son devis initial jusqu’à l’optimisation récurrente de ses coûts :

L’étape d’évaluation du budget associé à une application cloud

En phase de pré-projet, on va chercher à cadrer le budget associé à l’application. Une fois l’architecture définie, on va évaluer les coûts associés aux différents services cloud requis en s’appuyant sur un outil tel que : AWS Simple Monthly Calculator.

Pour réaliser ce devis, il est nécessaire d’avoir une compréhension détaillée du “workload”, ce qui est rarement le cas en phase de pré-projet. Cette évaluation pourra se faire de manière itérative en se basant sur les informations apportées par la création des environnements de développement.

Il est important que des représentants du métier, des équipes de développement, des opérations et des financiers soient impliqués sur cette phase de devis. Cela permettra de comprendre les éléments qui pourront permettre d’optimiser les coûts par rapport aux usages.

L’étape de définition des budgets

Une fois que les budgets sont validés, ils peuvent être suivi au niveau de la console “Budget”. Des alertes peuvent être déclenchées par rapport à un coût de consommation mensuel ou par rapport à une volumétrie d’utilisation des ressources (usage). Un rapport peut être communiqué automatiquement, présentant l’évolution des coûts de consommation par rapport au niveau d’alerte.

L’étape de déploiement des services clouds 

Les services clouds requis pour l’application sont déployés conformément à la stratégie de tagging définie par l’entreprise. En particulier certains tags pourront être utilisés pour regrouper des coûts : par exemple, le nom de l’application, le nom du domaine métier utilisé ou le nom du responsable de la ligne budgétaire concernée.

Il est important également que la stratégie de tagging, permette aussi d’identifier les coûts indirects (non liés à une application particulière : par exemple les coûts de la Transit Gateway) pour pouvoir ensuite les ventiler sur les différentes applications.

Pour les entreprises qui ont une stratégie multi Account où un Account est attribué par application, l’allocation standard des coûts par Account permet d’obtenir les coûts par application.

L’étape de suivi et d’analyse des coûts des services clouds 

Les alertes budgétaires peuvent être déclenchées par rapport à la prévision à fin de mois; il est donc possible d’être alerté en cours de mois si l’alerte est dépassée.

Les coûts actuels du mois peuvent être analysés au niveau du « Cost Explorer : Cost & Usage Report » afin d’identifier quels sont les services qui évoluent en termes de coûts et par rapport à quels volumétries d’usages.

L’étape de définition des plans d’optimisation

Des revues régulières de ces coûts peuvent être réalisées afin de partager la compréhension de l’évolution des coûts et d’identifier les optimisations potentielles. Nous préconisons d’intégrer le contrôle financier, les métiers, le développement, les architectes et les opérations dans ces revues. Ces revues sont destinées à comprendre l’impact financier :

• Des usages
• De l’architecture applicatives et infrastructures
• De l’automatisation
• Des modèles de réduction

Et d’identifier les mesures qui vont permettre d’optimiser les coûts.

Il est indispensable de corréler les volumétries d’usages des services avec des indicateurs métiers. Ainsi sur la montée en charge d’une application de maintenance préventive aéronautique, on va corréler le temps de traitement des données avec le volume/type d’avions et de vols pour lesquels on traitera les données par jour. Ceci permettra de corréler une montée en charge métiers avec une évolution de la volumétrie d’usage des services cloud (on s’appuiera soit sur CloudWatch, soit dans Cost Explorer sur les rapports par types d’usage).

L’étape de mise en oeuvre et d’évaluation des actions d’optimisation

Cette étape vise à mettre en place les différentes actions d’optimisation (voir des exemples concrets dans la partie ….) : évolution des usages, évolution de l’architecture applicatives, des services cloud et de leur paramétrage, de l’automatisation, de l’évolution des modèles de prix utilisés.

Une fois ces actions mises en place, on vérifie que le niveau de services attendu n’est pas impacté et que les coûts sont optimisés conformément aux attentes.

Attention ces optimisations ont un impact à usage métier égal. Le suivi des indicateurs métiers tels que préconisés ci-dessus permettra d’identifier si ces usages évoluent.

L’étape de capitalisation

Cette étape permet d’identifier et de communiquer des optimisations qui pourront être appliquées avec les mêmes bénéfices sur des applications qui ont des architectures de références semblables.

Ceci peut être réalisé par l’organisation d’événements de partage de bonnes pratiques d’optimisation au sein par exemple de la communauté des architectes cloud.

La capitalisation peut être également réalisées via des “politiques”, règles de configuration ou automatisation qui peuvent être appliquées de manière transversales : par exemple des politiques de gestion du cycle de vie par rapport à certaines typologies de données.

Établir une culture de l’optimisation

Réaliser ces différentes étapes et impliquer l’ensemble des parties prenantes permet une montée en compétences des différentes équipes et une sensibilisation en continu à l’optimisation des coûts. Le renforcement de cette culture peut être faciliter par l’animation d’une communauté cloud qui va accélérer la sensibilisation, le partage et la capitalisation.

Dans le prochain article de notre série consacré au FinOps, nous verrons en détail les bonnes pratiques pour optimiser sa facture.