Hé toi ! Tu éteins la lumière quand tu sors d’une pièce ? Tu penses à réduire ton chauffage quand tu n’es pas chez toi ? C’est bien, mais est-ce que tu penses à éteindre ton environnement de développement quand tu as fini de tester ton nouveau code et qu’il est déployé en production ? Est-ce que tu laisses tourner tes machines le soir et le weekend à rien faire et à consommer des ressources et de l’argent ?

Eh bien, par analogie, c’est comme si tu laissais couler ta douche pendant que tu regardes “Anouna” en claquettes-chaussettes dans ton salon en mangeant des chips. Tu consommes des ressources comme un tuche ! Non seulement ça te coûte de l’argent, mais en plus ça ne te rapporte rien et ça crame des ressources inutilement.

Je te propose de faire deux ou trois actions simples sans consommer trop de charges mentales pour réduire ta facture, mais aussi ton impact environnemental. Une fois n’est pas coutume, on se concentre sur GCP, mais les concepts sont transposables sur les autres fournisseurs de cloud et aussi dans ton propre environnement dans une moindre mesure.

Tout le monde le sait mais personne ne le fait

Tiens, concept ! Je vais commencer cet article par sa conclusion. La première chose à faire, c’est de se poser la question : “Est-ce que mon application est utile ?” Ok, ça semble hyper débile et réducteur, mais si je développe un peu l’idée, tu vas voir que ce n’est pas si con que ça en a l’air.

Est-ce que mon application rend un service unique et utile pour mon organisation ? Est-ce que ce n’est pas le délire d’un mec tout seul dans son coin pour remplacer un besoin en doublon dans une autre application ? Est-ce que ce ne serait pas mieux de mutualiser les ressources plutôt que de redévelopper ou installer un nouvel outil ? Est-ce que j’ai vraiment besoin de mobiliser de gros compute surdimensionnés “au cas où” ? Est-ce que mon retour sur investissement est bon, mon application me coûte moins qu’elle ne me rapporte ? Est-ce que mon application est consommée toute l’année ou est-ce que j’ai de longues périodes d’inactivité et mon trafic est seulement ponctuel ?

Bon, et les bases de données managées, on ne ferait pas un petit scheduler pour les éteindre tous les soirs en dev ? Les TensorFlow qui tournent sans jamais rien ingérer, est-ce qu’on ne les éteindrait pas tout simplement, on a créé un outil pour répondre à un besoin inexistant (comme le fait si bien Apple) mais personne ne consomme notre produit (contrairement à Apple) ?

Est-ce que les machines de dev nominatives ne devraient pas être éteintes quand les gens qui les utilisent sont en vacances ?

ça marche aussi avec Kubernetes

• Est-ce que j’ai vraiment besoin d’un cluster kube avec des nœuds aussi gros ?
• Est-ce que mon cluster scale de manière appropriée avec la bonne densité de pods dans mes nœuds ?
• Est-ce que j’ai besoin absolument d’un service mesh (qui rajoute des sidecars pods sur chaque pod) ?
• Est-ce que j’ai besoin d’ajouter un milliard d’outils de monitoring, de tracing, d’inspection (coucou Dynatrace) ?
• Est-ce que mon cluster de dev est obligatoirement obligé de rester allumé avec toutes mes versions de dev de mes microservices ?
• Est-ce que au lieu de toujours rajouter plus de pods, je prendrai pas le contrepied pour dégager quelques pods qui se touchent la nouille, voire de les mutualiser dans un microservice.

Le truc n’a pas besoin de scaler et manifestement, il ne fait pas grand-chose, ça vaut peut-être le coup de le rassembler avec ses amis glandeurs, ou d’aller cramer des ressources ailleurs ! Ah, et réduire les node pools à zéro node, ça marche pas mal aussi pour garder tous les manifests YAML dans le cluster sans consommer de nodes. On peut très bien péter et reconstruire le cluster tous les jours, mais parfois on peut aussi s’en sortir sans être dans l’extrême.

Je vous ai dèja parler de Cloudrun ?

Oui, je sais, vous en avez marre que je vous parle de Cloud Run, mais bon que voulez-vous, on ne se refait pas :) Pensez-y ! Cloud Run en accès public, s’il n’est pas appelé, ne coûte rien en finance et pour la planète, à condition d’assumer le cold start et d’accepter que de temps à autre, l’application qui est très rarement consommée mette un peu plus de temps à démarrer.

Mais attention, si vous faites plaisir à votre DSI, Cloud Run en accès privé nécessite des load balancers pour fonctionner. Les load balancers sont nécessairement des ressources computes qui restent allumées, même si votre Cloud Run lui reste tranquillement éteint.

Le réseau en général n’est pas votre ami, cela nécessite souvent des computes qui restent allumés (même si on ne les voit pas dans la console). Je ne dis pas qu’il ne faut pas faire de load balancers, mais pour vos finances et la planète, il vaut mieux mutualiser les ressources et éviter de multiplier ces équipements.

Attention, si vous mettez la contrainte d’avoir au moins un conteneur allumé en permanence, vous consommez du CPU autant que si vous aviez des computes normaux allumés. Du coup, si vous activez cette option, privilégiez surtout les environnements de production qui ont besoin d’un temps de réponse rapide et qui sont fréquemment requêtés. Si vous ne le faites pas, par analogie, cela revient à avoir un pod Kubernetes allumé en permanence à ne rien faire, ce qui est déjà mieux que trois, mais quand même, ce n’est pas la grosse folie.

Police du cluster, veuillez présentez votre manifest yaml !

Ouais, mais moi j’ai pas le temps pour tout ça, j’ai pas envie d’y penser

Je te propose de sortir tes petits doigts de dev, probablement coincés dans un endroit peu avouable, et de faire des Cloud Functions pour faire ça à ta place, sans jamais y penser :')

Il n’est surtout pas question de mettre des Cloud Functions dans l’ensemble de tes projets, il va falloir respirer un coup et donner des permissions un peu pétées transverses sur tes projets, au niveau d’un dossier qui contient tous les projets que tu veux gérer.

On oublie le Terraform qui ne sera d’aucun secours pour ce besoin. On pourrait le faire avec n’importe lequel des langages supportés par Cloud Functions, mais moi je choisis Python. Même si ce n’est pas le plus écologique, sa rapidité de prototypage et sa simplicité sont adaptées pour des tâches simples d’automatisation.

Voici une petite liste des choses que vous pouvez faire pour réduire votre facture. Je ne vais pas fournir de code, car j’ai mis certaines de ces actions en place chez mon client actuel, et je ne voudrais pas qu’on m’accuse de vol de code :) Cependant, je vais faire une liste des actions que vous pouvez mettre en place pour réduire votre facture et vos impacts carbone.

A chaque choix on parie contre le sort. Pas le choix faut y'aller. Dis leur que j'ai pas le temps - Faf Larage

Impact moyen en fonction de votre usage

• Mettre en place une politique de suppression sur Artifact Registry pour ne pas conserver tous vos builds depuis la nuit des temps.
• Mettre en place une politique de gestion du cycle de vie sur les buckets pour supprimer les objets trop vieux (par exemple, les sauvegardes périodiques de bases de données).
• Supprimer les images personnalisées Compute Engine trop anciennes.
• Supprimer les disques GCE qui ne sont pas utilisés.
• Supprimer les instantanés de disques trop anciens.
• Réduire les tailles des images Docker en respectant les bonnes pratiques.

Fort impact

• Choisir une zone cloud avec un datacenter à faible empreinte carbone.
• Éteindre systématiquement les VMs et les instances Cloud SQL des environnements de développement et de préproduction tous les soirs (et ne les rallumer que quand c’est nécessaire).
• Dimensionner raisonnablement votre environnement de production (en tenant compte des recommandations de Google sur les tailles de machines). -Éviter autant que possible d’utiliser des VM Windows (énergivores par rapport aux instances Linux).
• Éviter autant que possible d’utiliser Kubernetes et de traiter ses clusters comme des sources de ressources virtuellement inépuisables.
• Plutôt réduire le nombre de pods que d’en produire toujours plus et augmenter sans cesse les ressources consommées.
• Utiliser GKE Autopilot pour ne consommer que les ressources nécessaires pour vos pods, ou à défaut, calculer au plus juste vos nodes pour éviter la surprovisionnement de ressources.
• Utiliser Cloud Run/Cloud Functions par défaut pour les nouvelles charges de travail lorsque c’est possible, pour privilégier la consommation à la demande.
• Éviter d’utiliser BigQuery pour tout et rien et ne pas optimiser les requêtes.
  • BigQuery balance de la scalabilité horizontale pour répondre aux demandes.
  • C’est rapide, mais terriblement énergivore et coûteux, privilégiez plutôt les instances Cloud SQL quand c’est possible (mais pas MSSQL à cause de Windows).
• Éteindre les machines avec des GPU attachés dès que vous ne les utilisez pas, en plus d’être coûteux, c’est très énergivore.

Conclusion

Comme dit dans l’introduction, la première chose à faire avant de construire des machines, c’est de challenger le besoin. Est-ce que j’ai vraiment besoin d’allumer ces machines et si oui, il faut réfléchir à construire en amont des solutions les moins énergivores et coûteuses possible. La vraie bonne façon d’éviter une facture salée de compute, c’est de ne pas en avoir du tout. Attention aux services managés confortables comme BigQuery, qui en plus d’atomiser la planête, détruit votre portefeuille si utilisé à outrance.

Un cloud provider, c’est comme un casino : Au final, la banque gagne toujours !