Le Cloud n’est pas sur site
Les ingénieurs qui conçoivent l’architecture et provisionnent les nouvelles ressources dans le cloud prennent indirectement les décisions d’achat. Parfois plusieurs fois par jour ! Chaque décision affecte le montant total de la facture émise à la fin du mois par le fournisseur de cloud public.
Pour les organisations qui ont une longue histoire, c’est une toute nouvelle réalité. Il est difficile pour les départements financiers de s’y retrouver sans une planification à long terme des achats de matériel informatique et de licences. Par conséquent, ceux qui contrôlent les dépenses informatiques sont confrontés à un nouveau défi qui n’existait pas auparavant. Dans le modèle sur site, il est impossible de dépasser le budget une fois la commande passée. Quelle que soit l’utilisation des serveurs, leur coût d’exploitation était connu d’avance et, surtout, fixe.
La flexibilité du cloud a changé les règles du jeu. Les achats se font en quelques secondes, et les coûts varient en temps réel en fonction de l’utilisation en cours.
L’évolution des modèles suit celle de la technologie
Le développement de solutions basées sur le Cloud a rendu la planification des capacités obsolète, et les changements technologiques ont incité à développer de nouvelles pratiques au niveau de l’ingénierie et de la gestion des solutions.
Ce serait un cliché de dire que tout problème informatique peut être résolu de plusieurs façons. L’architecture décrit ces solutions. Tout architecte expérimenté admettra que l’architecture est une question de compromis et d’arbitrages. Toutefois, comme pour la sécurité, il n’est pas facile d’accepter des concessions importantes en matière de coûts.
Au groupe traditionnel d’exigences non fonctionnelles, telles que la disponibilité, les performances et la sécurité déjà mentionnée (il y en a beaucoup d’autres), il faut ajouter les coûts opérationnels de la solution. Les systèmes informatiques ne doivent pas être surdimensionnés et donc trop coûteux. Idéalement, les coûts de la solution devraient croître moins vite que le nombre de transactions qu’elle supporte. Cela démontre le choix de la meilleure architecture qui utilise de manière flexible, à notre avantage, les économies d’échelle, qui est l’un des principes de base du cloud public.
Comment faire face aux coûts élevés du cloud ?
Souvent, au début du voyage, et surtout au moment où les budgets prévus pour le cloud sont dépassés, le département financier est tenté de prendre en charge la sélection des technologies et de contrôler qui peut créer quoi et quand. Dans une certaine mesure, cette approche a du sens :
Par exemple, supposons que nous ne réalisions pas des millions de simulations lorsque nous travaillons sur un nouveau médicament. Dans ce cas, notre organisation n’aura pas besoin de coûteuses machines virtuelles équipées de cartes graphiques sur lesquelles ces calculs peuvent être effectués. L’accès à cette catégorie de serveurs peut donc être bloqué « de haut en bas », ce qui empêche leur lancement accidentel.
Malheureusement, l’approche ambitieuse d’un contrôle strict a de nombreux effets négatifs dont la direction doit tenir compte. Tout d’abord, elle bloque la plupart des avantages de l’utilisation du cloud public en :
- limitant l’accès aux nouveaux services et aux mises à jour (qui apparaissent au moins tous les trimestres et rendent souvent obsolète la « bonne » architecture actuelle).
- empêchant la construction rapide de PoC.
- évitant les expérimentations, privant ainsi les informaticiens de la possibilité de se développer en apprenant concrètement de nouvelles solutions.
Deuxièmement, le blocage informatique est une source de conflit et construit une culture du « nous contre eux ». Il place les programmeurs et les ingénieurs dans la position de personnes auxquelles l’organisation ne fait pas confiance et les contrôle donc avec des agents de la police financière.
La dernière raison pragmatique est que même les services initialement approuvés et testés peuvent être mal configurés, dupliqués ou abandonnés (quelqu’un les a utilisés une fois, puis a arrêté, mais a oublié de les supprimer – nous appelons professionnellement ces cas des déchets), générant ainsi des coûts inutiles.
À mon avis, les arguments ci-dessus sont suffisants pour décourager les abus de pouvoir et ne pas introduire un gatekeeping de grande envergure.
Alors, que faire pour contrôler l’augmentation des coûts du cloud ?
Avant de poursuivre, vous devez savoir que certains de ces coûts non planifiés peuvent être importants et appropriés car ils profitent à l’organisation. Le défi pour le département financier est ici de comprendre lesquels ! Vous devez apprendre à séparer le bon grain de l’ivraie et être capable d’optimiser les coûts dans le Cloud.
Comme nous l’avons mentionné plus haut, un système de pointe provisionnera ou détruira automatiquement les ressources du cloud en fonction de ses modèles d’utilisation. Nous dirons qu’il est élastique. Par conséquent, si vous avez prévu de servir une moyenne de 10 000 clients par mois et que vous avez estimé un budget pour un tel volume, vous devez tenir compte de certains événements. Par exemple, si une récente campagne de marketing a provoqué une augmentation de la demande pour les produits/services de votre entreprise, ce qui a entraîné une augmentation significative du nombre de clients et une mise à l’échelle du système, ce qui a augmenté les coûts.
Bien sûr, il s’agit d’un exemple positif (et espérons que c’est le seul cas pour vous) montrant l’étroite corrélation entre les affaires et la technologie. Des coûts plus élevés ne sont pas toujours un problème ! D’autres exemples sont plus difficiles à convertir en argent car ils sont difficiles à évaluer :
- le transfert des sauvegardes vers le Cloud,
- l’augmentation des tests d’applications sur les serveurs du Cloud,
- analyses et rapports Big Data,
- et bien d’autres encore.
Toutes ces mesures pourraient être prises pour gagner du temps et accroître la sécurité.
Si de telles décisions non planifiées et non maîtrisées peuvent être justifiées a posteriori, notamment parce qu’elles témoignent de l’expertise et de l’engagement du personnel technique, on ne peut ignorer qu’elles ne sont pas une règle et sont toujours associées à des coûts inutiles.
Diverses études de marché semblent estimer qu’en moyenne, 20 % des coûts du cloud sont inutiles. Certaines vont jusqu’à 35 % dans leurs estimations (ce que je suis enclin à croire au vu de mon expérience !). Même pour les petites et moyennes entreprises, cela représente des sommes considérables, atteignant des dizaines ou des centaines de milliers et souvent des millions de dollars par an.
Les coûts du Cloud doivent être optimisés avant tout dans ce domaine – en recherchant les économies et en éliminant les pertes !
Comment ? Voir le point 3 du paragraphe ci-dessous.
De nouveaux défis pour la « finance » dans le Cloud
À ma connaissance, la responsabilité du directeur financier ou du directeur des systèmes d’information dans le contexte de la finance en nuage est la construction au sens large de la culture FinOps, qui se compose principalement des questions suivantes :
1. L’allocation des coûts – une méthode d’affectation des coûts du cloud à des systèmes (projets) ou des unités organisationnelles spécifiques. Une tâche non triviale visant à créer des critères clairs pour assurer la transparence des mesures de coûts. Il est parfois difficile de séparer les coûts entre les projets ; des règles claires aideront les équipes informatiques à comprendre comment elles sont évaluées en interne.
L’une des premières tâches clés dans ce domaine sera de définir et de mettre en œuvre une stratégie de marquage des ressources.
À un niveau de maturité plus élevé, vous devrez choisir l’un des modèles de facturation : chargeback ou showback. Cela permettra de transférer une plus grande part de la responsabilité des coûts des solutions Cloud à la périphérie de l’organisation – aux équipes qui en sont responsables.
2. Diriger des activités visant à développer des pratiques et des normes internes facilitant la gestion et l’optimisation des coûts du cloud dès la phase de conception. Ces activités doivent être menées avec les départements techniques et les ingénieurs. Les tentatives d’imposer des règles tirées de livres et des meilleures pratiques sur Internet sont rarement couronnées de succès en raison des limites technologiques et culturelles.
La vérité honteuse est que les techniciens détestent les critiques sur les solutions qu’ils ont créées et les prennent assez mal de la part de personnes non techniques. Je recommande donc de mettre en place des mécanismes de coopération fondés sur le partenariat. La recette du succès : montrer aux départements informatiques l’objectif commun de faibles coûts d’exploitation. Les programmeurs et les ingénieurs adorent les défis. Présenter de faibles coûts (tout en maintenant d’autres exigences non fonctionnelles) comme une réalisation technique (de nature technique) sera cent fois plus motivant que tous les commandements et ordres émanant d’un département financier étranger.
Des motivations plus tangibles méritent également d’être envisagées ; peut-être qu’une partie de l’argent économisé par le projet peut « retourner » dans son budget, permettant ainsi l’embauche d’un autre membre de l’équipe qui s’en décharge ?
3. Lancer des activités visant à optimiser les coûts actuels et futurs du cloud. C’est la seule chose qui peut apporter une réduction immédiate des coûts de fonctionnement, surtout lorsqu’elle est effectuée pour la première fois, car elle offre généralement une série de fruits mûrs. Notre offre comprend précisément un tel service, et je vous encourage vivement à l’utiliser.
Mais attention, il ne s’agit pas d’une solution miracle à tous les problèmes de coûts !
Il est parfaitement raisonnable de commencer par cette étape même si d’autres aspects sont encore au stade de la planification. Toutefois, il faut savoir que c’est le responsable de la prise de décision qui est chargé de planifier la stratégie de construction de la culture FinOps dans l’organisation, de sorte que l’ensemble de l’activité est également axé sur la formulation de conclusions, le changement de la façon de travailler et la conception de l’architecture. Seule une telle approche peut permettre de réaliser des économies à l’avenir (évitement des coûts). Sinon, l’optimisation des coûts du cloud réduira temporairement la facture mais ne développera pas les compétences du personnel technique, ce qui entraînera la répétition des mêmes erreurs et de nouvelles factures élevées à l’avenir.
L’optimisation des coûts du Cloud en pratique.
Trois catégories conventionnelles
L’optimisation des coûts commence par l’analyse de vos factures actuelles et historiques et par la vérification de la nature et de la manière dont les services de cloud AWS sont utilisés par votre organisation (ou un système spécifique de votre compte AWS – selon l’ampleur de l’optimisation).
Sur la base de ces informations et d’un aperçu de l’architecture des solutions mises en œuvre, l’architecte-économiste prépare une liste de recommandations ainsi que l’estimation des économies générées une fois mises en œuvre. Ces recommandations sont très techniques.
D’après mon expérience, ces recommandations peuvent être divisées en trois groupes en fonction du temps et des ressources nécessaires à leur mise en œuvre :
- Simple & rapide – dans la plupart des cas, elles concernent des ressources mal configurées ou complètement redondantes mais n’affectent pas l’architecture de la solution. Le délai de mise en œuvre est de quelques jours, et parfois de quelques heures seulement ! Très souvent, vous pouvez constater l’effet de la réduction des coûts dès le lendemain.
- Moyen – ici, nous sommes confrontés à des problèmes qui nécessitent une plus grande planification. Une analyse supplémentaire de l’impact potentiel sur d’autres composants ou services de l’organisation est souvent nécessaire. Ceci est particulièrement important dans le cas d’opérations irréversibles, par exemple, l’arrêt de ressources potentiellement redondantes qui étaient initialement incertaines. Pour cette raison, on peut s’attendre à des réductions de coûts en quelques jours ou semaines.
- Complexe – cette catégorie exige toujours des changements importants dans l’architecture d’une solution qui ne sont jamais rapides ou faciles à mettre en œuvre. Il faut donc envisager une période de travail de plusieurs semaines avant de réaliser les économies estimées.
En pratique, cette catégorisation à trois niveaux est très pratique pour planifier une réparation et déterminer la séquence des actions.
Il convient de mentionner ici que notre subconscient nous égare et nous fait croire que seules les optimisations complexes apporteront des effets significatifs (remarquables) sur la facture. Rien ne peut être plus éloigné de la vérité ! Tout dépend du projet spécifique, des services AWS utilisés, de leur configuration et du volume d’utilisation.
Notre portefeuille comprend des exemples d’optimisations rapides et simples qui ont permis de réaliser des économies plus importantes que celles qui prenaient plus de temps.
Exemples de réussites en matière d’optimisation des coûts du cloud
Chez l’un de nos clients, nous avons effectué une analyse des coûts et mis en œuvre des recommandations concernant l’optimisation des disques dans le service EBS (Amazon Elastic Block Storage). L’optimisation rapide et simple des coûts a donné des résultats immédiats : des économies de 20%. Sur une base annuelle, le client a économisé environ 240 000 dollars.
Dans un autre cas de la catégorie Moyenne, nous avons identifié des gaspillages (ressources inutiles) générant 68 % du coût de l’ensemble du service. Sur une base annuelle, cela s’est traduit par 4 730 $ d’économies.
L’activité qui a demandé le plus d’efforts et de temps a été la modification de l’architecture de la solution pour réduire les coûts associés à Elastic IP. Il s’agissait évidemment d’un changement compliqué à effectuer. Avant le début des mesures correctives, le client payait près de 30 000 $ pour les adresses IP attribuées à des milliers de machines virtuelles EC2. Après plus d’un an de travail, les coûts ont été réduits de 67 %, à moins de 10 000 $ par mois. Sur une base annuelle, cela a permis d’économiser plus de 123 000 $.
Il est remarquable que le travail conceptuel n’ait exigé au départ qu’une participation importante des architectes et des ingénieurs à l’analyse et à la préparation de la nouvelle architecture réseau. La plupart des travaux pratiques ont été effectués par des employés moins qualifiés qui ont exécuté les étapes nécessaires sur chaque serveur EC2, économisant ainsi le temps des spécialistes les plus précieux.
Comme vous pouvez le constater, les exemples du monde réel montrent que les économies réalisées grâce à l’optimisation des coûts ne dépendent pas du niveau de difficulté et du temps nécessaire à la mise en œuvre. Parfois, les solutions les plus simples permettent de réaliser les économies les plus importantes, ce qui ne signifie pas que les solutions les plus complexes ne valent pas la peine d’être mises en œuvre.
Bien sûr, les économies totales (celles en dollars) dépendent du montant de la facturation, mais même les 4 730 dollars économisés par service AWS pour ce client représentaient environ 16 % des coûts AWS totaux et faisaient une réelle différence.
Quelle est la prochaine étape ?
Je sais que vous êtes bien conscient que l’établissement d’une culture FinOps est un changement organisationnel qui peut prendre des années.
Dans les situations où une action rapide est nécessaire, comme celles causées par des dépassements de budget, je recommande de procéder à une rapide optimisation des coûts pour obtenir des informations fiables sur les économies potentielles et des conseils techniques pour les réaliser.
Dans sa forme la plus simple, une telle analyse prend quelques jours. Évidemment, cela dépend de l’étendue des comptes AWS, des ressources et des services utilisés.
Les optimisations rapides et simples vous permettront de réaliser des économies tangibles et immédiates. Elles constitueront également votre success story qui ouvrira la voie de votre organisation vers les FinOps.