Coût du Cloud : Comment faire baisser la facture ?

LOUÉ POUR SA FLEXIBILITÉ ET LE PASSAGE D’UN MODE CAPEX À OPEX, LE CLOUD PUBLIC SÉDUIT SON MONDE. MAIS À LA FIN DU MOIS, LA FACTURE EST PARFOIS SALÉE ! IL EXISTE POURTANT DES MÉTHODES ET DES OUTILS PERMETTANT D’ALLÉGER LA DOULOUREUSE. POUR CELA, UNE RÈGLE D’OR : « DON’T RUN THE CLOUD LIKE A DATACENTER ! » Alors que les entreprises basculent de plus en plus d’applications et ressources IT sur le Cloud public, les factures mensuelles s’allongent et sont de plus en plus lourdes. En outre, avec ses centaines de services et les multiples options et suppléments facturés au volume ou à la durée d’utilisation, la complexité des factures AWS est devenue légendaire. Une nouvelle discipline est en train de monter en puissance, c’est ce que l’on appelle le FinOps, ou l’art d’optimiser le volet budgétaire du Cloud. AWS met en avant les gains immédiatement engrangés lors d’une migration de ressources on-premise vers son Cloud public Amazon. « Les analystes d’AWS Cloud Economics ont étudié les factures de 125 entreprises ayant migré sur AWS, les économies réalisées vont de 26 % à 49 % sur l’infrastructure », argumente ainsi Alexis Dahan, Account Manager chez AWS : « Le plus gros levier d’économie est de pouvoir adapter leur système d’information aux besoins réels, pouvoir adapter l’infrastructure à un niveau très fin, et donc adapter au plus juste les ressources à la consommation et bénéficier de ces économies d’échelle. » L’étude a été réalisée sur les clients sur AWS depuis six mois, mais Alexis Dahan estime qu’au-delà de la première phase de « lift and shift » des applications vers le Cloud, les entreprises peuvent encore abaisser leurs coûts de manière significative en basculant certaines briques du SI vers des services managés, en réduisant la taille des instances, et ayant recours aux instances réservées.

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. »