Cloud responsable et FinOps : un duo qui marche !

A l’heure actuelle, vous n’êtes pas sans savoir que le cloud ne cesse de se développer sur le marché des nouvelles technologies. Ses plus gros fournisseurs proposent un large choix de services répondant à une liste grandissante de problématiques et de cas d’usage. Et bien que cela soit très intéressant pour les entreprises. La multiplication des datacenters, données, applications et utilisateurs entraîne inévitablement une augmentation de ses émissions de gaz à effet de serre.

Le message que je souhaite faire passer dans cet article est qu’il faut rester vigilant et adopter d’ores et déjà les bonnes pratiques pour suivre une démarche responsable. Et la bonne nouvelle, c’est que dans cette mouvance, « bonnes pratiques » rime avec « économies » ! A la lumière des sujets Green IT et FinOps que j’ai pu mener au cours de mes missions, je vous expliciterai ici comment nous appliquons notre démarche RSE à travers le prisme de l’architecture technique dans le cloud.

Quels leviers pour diminuer au mieux son empreinte ?

Le choix de processeur

Pour les services non serverless, il vous est possible de choisir jusqu’au processeur sur lequel vous souhaitez que vos applications reposent. De ce que j’ai pu observer en mission, ce premier point fait déjà la différence !

A titre d’exemple, l’hyperscaler Amazon Web Services propose depuis 2018 ses propres processeurs ARM, nommés Graviton. Ces derniers peuvent supporter des charges de travail optimisées, en offrant de meilleures performances, une plus faible consommation d’énergie, et tout cela à coûts réduits par rapport aux autres processeurs.

L’utilisation de gabarits d’instance de dernière génération

Le second point sur lequel j’attire votre attention est qu’il est important de maintenir son parc d’instances (VM classiques, bases de données managées…) à jour. En d’autres termes, vos applications doivent toujours être hébergées sur des instances de dernière génération. Celles-ci consomment moins d’énergie, sont plus performantes, resteront maintenues par le fournisseur sur une plus longue durée et coûtent moins cher que les générations précédentes.

Ajustement des gabarits d’instance

Pour traiter cette problématique, la meilleure solution est de faire comme à la maison : du ménage périodique ! De cette manière, vous pourrez redimensionner les ressources des applications qui en ont besoin, et supprimer celles qui ne vivent plus. Et si vous voulez agir de manière plus efficace, n’hésitez pas à utiliser des services serverless ou encore de l’auto-scaling : ils s’occuperont de l’ajustement à votre place en réajustant, en éteignant ou en supprimant les ressource que vous n’utiliserez pas. Voilà une bonne chose de faite !

Mise en place de plages de service ajustées

Vous avez la possibilité de définir les créneaux horaires durant lesquels vos ressources fonctionnent, alors pourquoi s’en priver ?

Pour vous donner un cas concret, si vous travaillez sur vos environnements hors production uniquement en période ouvrée, vous pouvez démarrer et arrêter les ressources associées grâce à un programme qui s’exécute aux horaires désirés (ex : Instance Scheduler sur AWS). Et même dans le cas des environnements de production, si vos applications ont vocation à être utilisées uniquement en horaires ouvrés, vous pouvez choisir d’interrompre leur fonctionnement le reste du temps. Vous pouvez ainsi réduire de deux à trois fois votre facture !

Optimiser l’utilisation des services en fonction de l’usage

Si je reprends l’exemple d’AWS, le fournisseur propose divers services qui permettent de réduire les coûts et les émissions carbone associées en fonction de la fréquence d’utilisation des données qui y sont stockées. Ainsi pour vos compartiments Amazon S3 ou encore vos systèmes de fichiers Amazon EFS, si vous répartissez vos données peu accédées voire pas du tout respectivement dans les classes de stockage d’accès peu fréquent ou d’archivage, ces données seront compartimentées dans des espaces de stockage avec peu voire pas de transferts sortants. Et qui dit peu de transferts, dit peu de téléchargement et d’accès utilisateurs, dit moins de consommation d’énergie et d’émissions de gaz à effet de serre. Bien évidemment, cela se reflète également sur la facturation.

Visualiser votre parc

Tout cela me paraît déjà très bien, cependant vous pouvez ajouter un axe complémentaire et garder un œil sur l’évolution de votre parc de ressources, vous permettant ainsi de savoir combien vous émettez et dépensez.

Pour ce faire, vous pouvez :

• Recourir aux tableaux de bord mis à disposition par votre fournisseur (ex : Customer Carbon Footprint Tool sur AWS, ou l’outil Empreinte carbone de GCP)
• Développer votre propre solution à partir des outils, méthodologies et référentiels de données existants (ex : Cloud Carbon Footprint, ou encore Boa Vizta).

Bien que les solutions et standards de calculs d’empreinte carbone de cloud soient encore en cours de développement, ils permettent déjà de suivre un certain nombre de services. D’autre part, ils nous font constater une chose très intéressante : les courbes d’émissions et les courbes de dépenses sont sensiblement les mêmes par rapport au temps, ce qui montre là un réel lien entre les deux aspects.

Nous sommes loin d’être à court d’options

Vous l’aurez constaté, il existe divers leviers qui permettent d’optimiser sa consommation d’énergie dans le cloud, et donc ses émissions de gaz à effet de serre associées. Pour ma part, je ne vois que de bonnes raisons d’optimiser la constitution d’un parc de ressources, pour le bien de la planète et du porte-monnaie. Si vous souhaitez traiter cette problématique au sein de votre organisation, n’hésitez pas à nous contacter sur https://pramana.fr/contact/ !