3 minutes
Chez RCA il nous paraît important de tout mettre en œuvre pour diffuser la culture tech auprès de tous les collaborateurs, quel que soit leur métier. Nous lançons donc une série d’articles pour vulgariser nos sujets techniques et pas que !
Cet article fait suite à un premier publié expliquant la migration de nos services vers le cloud AWS. N’hésitez pas à le lire avant de vous lancer dans la lecture de celui-ci.
FinOps : la philosophie du “Picsou du cloud”.
Vous connaissez Picsou ? Son objectif : dépenser le moins d’argent possible pour un service ou un produit.
La démarche FinOps pour “Financial Operations”, c’est un peu la même vision… mais appliquée à la gestion du cloud.
Le fonctionnement de MEG : Cloud, VM, Pods et Kubernetes.
Avant de plonger dans la démarche FinOps, un rappel technique s’impose.
MEG, une plateforme qui vit dans le cloud.
MEG est accessible en ligne grâce au cloud (AWS). Pour fonctionner, la plateforme s’appuie sur des machines virtuelles (VM), qui sont comme de multiples ordinateurs au sein d’un serveur hébergé à distance, et sur des Pods, des blocs d’applications gérés automatiquement, le tout piloté par une technologie appelée Kubernetes.
Pourquoi la facture a augmenté après la migration ?
Chez AWS tout est facturé, l’activité de l’infrastructure déployée pour faire fonctionner MEG : les VM et les Pods. Juste après la migration, l’équipe Platform a préféré assurer un maximum de disponibilité pour nos clients en surdimensionnant l’environnement et être au rendez- vous pour cette grande bascule — une décision qui a logiquement fait grimper la facture.
Objectif FinOps : trouver le bon équilibre entre performance et coûts.
Il nous fallait un système qui ajuste automatiquement les ressources en fonction des besoins réels des utilisateurs.
Pour cela, l’équipe plateforme s’appuie sur trois composants :
- Kubernetes
- Keda
- Karpenter
Comment Keda, Karpenter et Kubernetes optimisent automatiquement les coûts.
Kubernetes : le chef d’orchestre,
Kubernetes fait tourner les applications dans des conteneurs et gère l’ensemble automatiquement.
Keda : l’auto-scaling intelligent des pods,
Keda ajuste automatiquement le nombre de pods en fonction de la charge ou de plages horaires d’activité, en ajoutant ou en supprimant des instances selon les besoins.
Karpenter : l’ajustement automatique des VM,
Karpenter ajoute ou supprime les VM nécessaires pour accueillir les Pods en fonction de leur nombre souhaité.
Le fonctionnement global.
Quand le trafic augmente :
- Keda ajoute des pods
- Karpenter ajoute des VM pour accueillir ces nouveaux Pods
Quand le trafic baisse :
- Keda réduit les Pods
- Karpenter éteint les VM inutiles
Résultat : une plateforme dynamique… et une facture flexible 💰
Le paramétrage FinOps : aligner la plateforme avec la réalité des usages.
La clé de la démarche : comprendre les habitudes de nos utilisateurs.
Adapter les ressources aux horaires réels de connexion.
Nos utilisateurs se connectent principalement aux horaires de bureau, entre 8h et 19h.
C’est donc sur cette plage horaire que la plateforme doit disposer du maximum de ressources.
En dehors de ces heures, Keda et Karpenter peuvent réduire les ressources — sauf si l’on fixe des plages de sécurité sans réduction.
A terme, l’équipe Platform souhaite faire fonctionner ces composants selon la charge en temps réel et plus seulement selon un calendrier horaire prédéfinis. Cela permettrait une optimisation plus pointue de la mise à disposition des environnements et donc une facture encore plus proche de nos besoins et de l’usage de nos utilisateurs.
Conclusion : une relation plus mature avec notre cloud provider.
Même après une lune de miel un peu coûteuse, il est possible de construire une relation stable avec son Cloud provider (AWS).
Chez RCA, le FinOps est devenu notre boussole : offrir le meilleur service tout en maîtrisant nos dépenses — de quoi permettre à notre Picsou maison de dormir tranquille.
*Toute référence à Picsou est bien sûr fictive : toute ressemblance serait purement fortuite.




