Le calcul du TCO de l’infrastructure cloud s’automatise
Les spécialistes estiment qu’une démarche d’optimisation des coûts du Cloud doit se décomposer en quatre étapes ; la première étant de mesurer l’activité réelle des applications. Cette phase de tracking peut même être menée sur les machines virtuelles des machines on-premise afin d’évaluer au plus juste quelles seront les instances cloud nécessaires pour faire tourner l’application qui va basculer dans le Cloud en mode « Lift and Shift ». « Avec notre outil Cloudamize, on place des agents sur les VM on-premise de nos clients afin d’analyser le comportement réel des applications en production, ce qui permet ensuite de délivrer un TCO de la même plate-forme sur AWS, GCP, Azure », explique Raffaële Azuelkos, Business Development Consultant chez CloudReach. « L’optimisation financière de la plate-forme doit être pensée dès le début du projet de migration vers le Cloud, depuis la définition du socle de base, la “ landing-zone AWS ” puis la gouvernance et le pilotage de la plateforme par les coûts. » Le prestataire compte Eurostar et GRTgaz parmi ses clients et assiste les entreprises dans le design de leurs architectures cloud, l’optimisation de ces architectures. « La démarche FinOps va bien au-delà de la phase de mise en place de la plate-forme, mais se prolonge tout au long de sa vie. Notre outil Cost-Control délivre chaque mois à nos clients des recommandations pour optimiser leurs coûts opérationnels. La première recommandation porte sur le volet scheduling des ressources. Éteindre la préproduction le soir et le week-end, c’est une économie de 30 %. Viennent ensuite des logiques de resizing à appliquer, beaucoup de données qui sont analysées en permanence afin de pouvoir envoyer à nos clients des recommandations d’optimisation de manière mensuelle. »
Préalable à un projet de type « Lift and Shift » vers le Cloud, des agents logiciels permettent d’identifier les machines virtuelles à migrer, la taille des instances nécessaires et indiquent un premier coût prévisionnel qu’il va ensuite falloir optimiser.
Exploiter au mieux les services proposés par le CSP
Un certain nombre de bonnes pratiques doivent être mises en place afin d’exploiter au mieux les grilles tarifaires des Cloud Providers. Il faut rapidement apprendre à jongler entre les instances provisionnées à la demande, les plus coûteuses, les « Reserved Instances », les « Spot Instances » et les « Dedicated Instances » qui permettent d’accéder aux mêmes ressources, mais à prix plus ou moins cassé. Omar Bouabidi, Cloud Architect & Business Developer chez Agyla, livre quelques règles simples à appliquer : « Il faut généralement réserver le mode on-demand aux workloads dont l’évolution est difficile à prédire. Les instances réservées permettent déjà de faire des économies sur des workloads dont on sait qu’on aura besoin d’instance sur un an, trois ans. Très peu de nos clients utilisent aujourd’hui les Spot Instances alors qu’elles présentent un potentiel d’économies énorme, notamment lorsqu’il faut absorber des pics de charge de quelques minutes, quelques heures. Par contre, lorsque l’entreprise a des contraintes spécifiques, qu’il s’agisse de réglementation ou de licences logicielles, il faut se tourner vers les instances dédiées. » La règle d’or à appliquer est d’oublier le mode de fonctionnement du datacenter classique, avec des machines qui fonctionnent en permanence. Inutile de maintenir en production des instances en 24/7 lorsque celles-ci ne sont utilisées qu’aux heures de bureau ; inutile de mettre en place des configurations de haute-disponibilité là où il est possible de se contenter d’une simple tolérance aux pannes. Les schedulers proposés par certains fournisseurs cloud permettent de programmer l’arrêt et le redémarrage d’instances, il est même possible de déclencher des séquences d’actions avant l’extinction ou après le redémarrage d’une instance.
AWS recommande de mélanger les instances provisionnées à la demande classiques, les instances réservées et les instances spot afin de faire face aux fluctuations de charge au meilleur coût.
Des outils d’optimisation de plus en plus évolués
De plus en plus de services et logiciels viennent en aide aux administrateurs pour optimiser la consommation des ressources cloud, qu’il s’agisse des solutions de Cloudreach, de Cloudhealth/ VMware, mais aussi Turbonomic, la solution de « workload automation » utilisée par Sephora, EDF, Chanel ou encore les solutions telles que CA Workload Automation AE qui ont appris à dompter les services cloud. Il ne s’agit plus seulement d’avoir un rapport quotidien ou mensuel sur l’utilisation des ressources, mais bien de mettre en place des processus qui vont automatiquement démarrer/arrêter des ressources en fonction de leur utilisation réelle, passer d’un type d’instance à un autre pour accompagner une montée en charge et ce, de manière totalement automatisée. Les outils vont de plus en plus loin dans leurs capacités analytiques et certaines solutions mettent en œuvre des algorithmes de Machine Learning pour identifier les patterns d’utilisation des services et piloter les ressources cloud en mode prédictif. Avec ou sans IA, les chiffres avancés par les éditeurs et les prestataires de services spécialisés font état de baisse de prix allant de 30 % à 50 % avec une analyse fine des données de fonctionnement délivrées par les fournisseurs cloud. Ces données peuvent être exploitées pour alléger la facture, mais aussi pour permettre à la DSI de refacturer en interne les services consommés sur le Cloud public. Déjà mise en œuvre par l’activité Banque d’investissement de la Société Générale, L’Oréal, Air Liquide, Total, Système U, l’application Apptio est un outil de pilotage de la dépense informatique qui veut aller au-delà de la seule optimisation des services cloud. L’éditeur rapproche ces données d’exploitation cloud et on-premise des données purement financières et les données issues d’un ServiceNow, d’un PeopleSoft. « Nous avons construit un modèle standardisé de la structure des coûts IT, qui permet d’atteindre une transparence des coûts IT, aussi bien on-premise que dans le Cloud public », explique Gilles Vincent, Senior Sales Consultant EMEA Alliances Apptio : « L’objectif est d’obtenir le TCO d’un service ou d’une application et éventuellement faire du charge-back de l’utilisation de ces ressources aux Business Units correspondantes, en y intégrant des règles liées aux équivalents temps pleins, par exemple, ou en fonction d’un nombre de transactions, etc. »
Les solutions d’optimisation des coûts des ressources cloud délivrent des rapports quotidiens ou mensuels afin d’indiquer des pistes de réduction des coûts.
Le tagging, ou la clé d’une stratégie de charge-back fiable
Pouvoir fournir un calcul détaillé aux directions métier (Show-Back) ou éventuellement les refacturer précisément sur la consommation réelle des ressources cloud (Charge-Back) implique avoir mis en place une stratégie stricte de tagging des ressources. Il faut donner à chaque instance, chaque ressource un nom (le tag) qui va permettre de savoir à quelle application, à quelle direction métier elle appartient. Le plan de tagging correspond à une CMDB temps réel du système d’information cloud, mais selon Gilles Vincent peu d’entreprises ont réellement fait l’effort d’imposer une stratégie de tagging globale : « La gestion du tagging reste un gros problème chez de nombreuses entreprises », reconnaît-il. « Contrairement aux serveurs que l’on va installer dans son datacenter, lorsqu’on crée une instance sur un service cloud, on ne maîtrise pas la convention de nommage des ressources. Pour pallier cela, les CSP proposent de placer des tags sur l’ensemble des ressources consommées par l’entreprise. Notre solution va s’appuyer sur ces tags mais elle peut aussi repérer où ces tags sont manquants. Très souvent ce sont entre 30 et 60 % des ressources qui ne sont pas tagguées correctement, donc autant de dépenses qui ne peuvent être réaffectées aux métiers. »
Des solutions telles que Turbonomic (ci-dessus), Cloudreach Sceptre ou Apptio permettent d’automatiser la reconfiguration dynamique des infrastructures en fonction du besoin réel afin de limiter les coûts de fonctionnement.
Nabil Ben Nasrallah, Cloud Architect et FinOps Expert chez Agyla, insiste sur l’importance de la stratégie de tagging dans l’approche FinOps mais aussi sur une gestion stricte des comptes cloud : « Il faut aussi faire attention aux accès aux comptes AWS, ce n’est pas seulement un problème de sécurité, mais aussi un problème économique. Ces utilisateurs peuvent créer ou modifier des ressources hors budget initial et potentiellement générer des dépassements de budget. » Cette problématique n’a rien d’anecdotique chez les grandes multinationales qui utilisent parfois plusieurs dizaines voire centaines de comptes AWS/Azure ou Google à travers le monde. En outre, cela entraine aussi des surcoûts d’abonnement aux services support qui ne sont pas utilisés. L’expert précise : « Des niveaux de support élevés sont parfois activés sur tous les comptes sans que ce support ne soit réellement utilisé. Il faut n’activer le support Business ou Premium que sur certains comptes de production et non pas les comptes dédiés aux développements, sachant que les développeurs pourront toujours utiliser le compte production pour poser leurs questions. »
Désormais, il n’y a plus de projet de migration cloud de grande ampleur sans un volet FinOps et il est acquis que les DSI vont devoir se doter de profils ultra-spécialisés afin de faire baisser leurs factures cloud, comme l’ont déjà fait les plus avancées dans leur maturité cloud. ❍
« Finops, une démarche en 4 étapes »
Nabil Ben Nasrallah, Cloud Architect et FinOps Expert chez Agyla
« Une démarche FinOps se compose de quatre grandes étapes. Le point de départ, c’est le tracking : il faut avoir une visibilité de toutes les ressources cloud avant de passer ensuite aux phases de monitoring puis analyser des performances de chacune de ces ressources. La troisième étape consiste à la prévision. Il faut prévoir l’évolution des usages et des coûts associés afin de définir le budget prévisionnel pour les années à venir. Enfin, la phase d’optimisation de l’architecture permet de n’utiliser que ce qui est réellement nécessaire. La phase de tracking doit permettre de segmenter les coûts par projet, par utilisateur/propriétaire de chaque ressource, au moyen du tagging de ces ressources cloud. »
« Il faut mettre en place des unités d’œuvre métier pertinentes »
Roland Esnis, directeur général de Gekko
« Paradoxalement, la réduction des coûts du Cloud n’est pas nécessairement la priorité des DSI des grandes entreprises qui font appel à nous. Les grandes entreprises initient souvent leur approche FinOps par le pilotage budgétaire, la réallocation des dépenses vers les métiers, et n’évoluent vers l’optimisation que lorsqu’elles sont plus matures. Les entreprises de tailles plus modestes commencent directement par l’optimisation des coûts, car leurs moyens sont comptés et elles ont moins de mal à aligner les différents acteurs de l’entreprise dans cette stratégie. Chez nos clients les plus matures, on met en place des scorecards. On fixe des objectifs d’amélioration à suivre, mais ce qui est important dans une telle approche est de créer des unités d’œuvre qui soient compréhensibles par les métiers. Une facture qui augmente n’est pas un problème en soit si les ventes ou la production augmente en parallèle : mettre en place les bonnes unités d’œuvre pertinentes permet de savoir si l’entreprise est réellement efficace dans sa maîtrise des coûts, ou non. »
« En appliquant ces règles d’optimisation adaptée à l’usage réel, nous avons divisé par trois notre facture AWS »
Fouad Maach, directeur du projet MoveToCloud de Veolia
« Il faut collecter de la Data sur les serveurs bare metal ou virtuels au moyen du AWS Discovery Agent. Ces données sont à la fois utiles pour faciliter la migration, mais aussi pour réaliser des économies. En effet, les données d’utilisation des CPU, de la mémoire et des disques vont permettre de redimensionner les serveurs dès le moment du “ lift and shift ” avec d’énormes économies à la clé. Ensuite, en fonction de la région cloud, il y a deux axes d’optimisation des instances possibles : la famille d’instance et la taille de l’instance. En s’appuyant sur l’usage réel mesuré des instances, on va basculer d’un catalogue de cinq à dix instances on-premise à un catalogue de plus de 170 instances chez AWS. Cela permet d’identifier la famille d’instance et la taille d’instance optimale correspondant au besoin réel et non pas aux préconisations parfois fantaisistes des éditeurs. Cette approche nous a permis de diviser par deux la taille de nos instances. Il faut profiter de la migration vers le Cloud public pour corriger cette sur consommation. Hors optimisation, nous avions déjà un ROI positif mais en appliquant ces règles d’optimisation adaptée à l’usage réel mesuré, nous sommes parvenus à diviser par trois la facture AWS, tout en appliquant des règles conservatrices, c’est-à-dire une marge de 20 à 25 % sur les capacités mémoire et CPU nécessaires. »