Thread by @le_trappiste

Il y a 2 semaines j'étais à Amsterdam pour la #KubeConEU 2023 et la keynote "Building a Sustainable, Carbon-Aware Cloud: Scale Workloads and Reduce Emissions" m'avait bien hypée jusqu'à ce que cette slide me file le hocquet...

Je vous décortique ça 🧶👇

D'abord c'est quoi la "KubeCon" ?

C'est une convention organisée par la @CloudNativeFdn qui regroupe tous les acteurs de l'écosystème #Kubernetes et plus largement la communauté #CloudNative, et là je me dis que l'intro va être longue, mais c'est intéressant, vous allez voir.

Il y a une KubeCon par an en 🇪🇺 et aux 🇺🇸 (et bientôt aussi en 🇨🇳...) et ça attire de plus en plus de monde chaque année:

10k participants sur place à Amsterdam cette année (!), et beaucoup plus à distance et en différé: youtube.com/@cncf/playlist…

L'édition 🇪🇺 2024 sera à Paris 🇫🇷

CloudNative, Kubernetes (k8s pour les intimes, ça se dit "k-eights"), kézako ?

Impossible à détailler maintenant, mais je vous invite à visionner cette vidéo de @Cookieconnecte qui présente tout ça de façon très accessible:

Notez en tout cas que k8s est devenu LE standard industriel de l'hébergement d'applications Web.

La plupart des services en ligne que vous utilisez tournent dessus, à commencer par celui sur lequel vous lisez ces lignes (depuis 2019): linux.com/news/twitter-a…

Google en est à l'origine mais il a été adopté par tous les acteurs de l'Internet, à commencer par ses principaux concurrents dans l'hébergement cloud: Amazon et Microsoft.

C'est ce dernier qui officiait durant la keynote dont je vais parler maintenant.

Cette keynote est présentée par @jorgefpalma, un haut responsable produit chez @Azure, le service cloud de Microsoft, et concerne le dimensionnement automatique (auto-scaling) d'appli en fonction des émissions carbone.

L'informaticien amateur d'énergie que je suis est capté.

Mais comme dans toute industrie, les grand acteurs de l'informatique n'ont d'autre choix que de beaucoup communiquer sur la soutenabilité de leurs services, et comme dans toute industrie, le greenwashing n'est jamais loin, donc il faut être attentif aux détails.

Ici, le public est spécialiste de l'IT, le discours se doit donc d'être concret sur cet aspect, mais le sera-t-il sur le plan énergétique ?

On commence par montrer des éoliennes. Soyons charitables, c'est de l'illustration, mais s'annonce déjà un côté "renewables magic".

Plusieurs slides et concepts sont repris de la @gsfcommunity.

Je ne connaissais que de nom et, en parcourant leur site, on trouve du bon...et du moins bon.

Cette carte par exemple, sans source ni chiffre, place l'🇩🇪 comme plus "🍃" que 🇮🇪🇬🇧🇳🇱 et pour 🇫🇷, on sait pas, déso 🤷‍♂️

Dites donc, @ElectricityMaps fait partie de vos membres, et ils donnent une image assez différente (données agrégées 2022).

Vous êtes surs que vous parlez de "l'intensité carbone" comme mentionné dans le texte autour ?
learn.greensoftware.foundation/carbon-awarene…

Tout semble indiquer que sont considérés comme plus "🍃" les mix avec plus d'EnR, sans considération de l'intensité carbone de la part non-EnR.


Pourtant, leur quiz dit bien que switcher vers les EnR n'est pas du "cloud aware computing".

Etrange...

La keynote mène ensuite sur cette fameuse slide, sans source et que je ne retrouve nulle part, ce qui laisse supposer que Microsoft en serait à l'origine.

Pas sûr que tonton Bill aurait tout à fait validé...
fr.wikipedia.org/wiki/TerraPower

Encore une fois, je suis charitable. Ce talk va être vu par plein de monde, ne pas entrer dans le débat pour ou contre le ☢️ me semble parfaitement logique.

Mais dans ce cas, pourquoi avoir choisi ce 🤬 de visuel pour illustrer "l'énergie sale" ?
youtube.com/clip/Ugkxwa5RZ…

Est ensuite introduit le concept d'intensité carbone, avec une slide de @gsfcommunity où le gaz est devenu bleu (déso mais @Shell est sponsor...).

Puis on arrive dans le concret avec un "opérateur Keda carbon-aware", et...je...vais devoir revenir un peu à la technique. Désolé.

Un opérateur est un programme qui va surveiller certaines configurations créées par l'utilisateur sur k8s et réaliser des actions en fonction de ce qu'il trouve.

Cela permet d'étendre les fonctionnalités de k8s de façon virtuellement illimitée et, oui, ça pourrait faire le café.

@kedaorg est un opérateur permettant d'étendre les capacités d'auto-scaling natives de k8s, c'est à dire d'📈ou 📉 automatiquement les ressources matérielles allouées à une application (en jouant sur le nombre d'instances de l'appli) en fonction de critères très diversifiés.

L'utilisation principale de l'auto-scaling (k8s ou pas) est d'adapter les ressources allouées à l'application en fonction de critères de charge ou de performance (s'il y a plus de monde, ou que l'application ralentit, on alloue plus de ressources, sinon on réduit la voilure).

C'est d'ailleurs une grande force du cloud, méconnue du grand public: on n'utilise que ce dont on a besoin, au moment où on en a besoin, alors qu'avant le cloud, on avait des serveurs, achetés ou loués pour des années, qui tournaient en permanence, qu'ils soient utiles ou non.

Je fulmine quand j'entends que les géants du cloud sont des horreurs écologiques, car il ne faut vraiment pas avoir connu les datacenters à l'ancienne et le gaspillage d'énergie qui allait avec pour dire ça.

Serveurs allumés en permanence, clims mal entretenues, et j'en passe.

N'utiliser que ce dont on a besoin, c'est la définition de la sobriété, et c'est ce qui a permis aux datacenters de garder une consommation d'énergie stable malgré une charge de travail et un trafic qui explosaient.

Ce n'est pas exempt d'effet rebond, et on peut s'interroger sur ce qu'on considère comme "besoin", mais sans les innovations du cloud, on aurait très bien pu cumuler ébriété d'usage et inefficacité énergétique (coucou #Bitcoin).

Et il va sans dire que ces gains d'efficacité fûrent motivés par des considérations plus économiques qu'écologiques.

Initialement, l'auto-scaling visait évidemment à corréler au plus proche les coûts d'infrastructure avec le chiffre d'affaire généré par les applications.

Mais alors, à quoi bon auto-scaler des applications selon d'autres critères ?

Hé bien principalement pour des traitements qui ne sont pas directement liés à la charge induite par les utilisateurs.

Les hébergeurs cloud proposent depuis longtemps des serveurs "spot" au tarif très avantageux (~70% moins cher) mais qui ont l'inconvénient de pouvoir être arrêtés en quelques minutes à n'importe quel moment si la dispo de serveurs au tarif normal venait à baisser.

Les appli "cloud native" sont conçues pour tirer le meilleur parti de ce principe, en déplaçant les charges de travail qui peuvent attendre dans des files d'attente qui seront traitées quand la capacité de traitement la moins chère sera disponible.

On parle de "background jobs".

Et c'est principalement ces jobs qui sont ciblés par cet opérateur Keda carbon-aware.

Son code se trouve ici et le README l'explique bien:
github.com/Azure/carbon-a…

Et à votre avis, quels sont les critères pour démarrer/arrêter ces jobs ?

On démarre quand il y a beaucoup d'électricité "🍃" et on coupe quand c'est 💩 ?

Bien évidemment que non. Le seul critère, c'est l'intensité carbone. La distinction clean/dirty n'apparait nulle part.

Ici, vous voyez une config de l'opérateur où l'on définit le max d'instances de l'appli en fonction de seuils d'intensité carbone, suivis d'une fenêtre de temps où la "carbon awareness" est désactivée.
("recurringSchedule" n'est pas clair mais c'est ce qui est écrit dans la doc).

Donc déjà, l'intérêt d'inclure les slides "🍃 vs. 💩" dans la présentation devient beaucoup moins évident.

Ces critères n'ont rien d'exploitable. Seule l'intensité carbone compte, et bien entendu que cela classe le nucléaire dans les énergies propres.

Mon dernier point sera sur l'utilité concrète de ce genre d'innovation.

Azure comme tous les cloud providers mondiaux est architecturé par "régions", c'est à dire des plaques de plusieurs datacenters proches très interconnectés, où l'on peut déployer ses ressources.

Quand je déploie une ressource (serveur virtuel ou autre), je ne sais pas exactement dans quel datacenter elle se trouvera (d'autant qu'elle peut bouger au fil du temps), mais je sais dans quel pays elle se trouvera...et donc...dans quel mix.

On peut donc imaginer qu'un utilisateur soucieux de son empreinte carbone aura le réflexe de privilégier une région dont le mix est globalement peu carboné, ce qui jouera aussi bien sur ses background jobs que sur ses charges ne pouvant être auto-scalées en fonction du carbone.

Car même en réglant le plus finement possible son scaling pour ne travailler qu'aux heures les moins carbonées, sachant qu'en 2022, l'Allemagne n'a pas eu UNE SEULE heure avec un mix moins carboné que la France (année pourtant difficile),

je ne vois pas comment on peut prétendre se soucier de ses émissions, et déployer la moindre ressource dans une région allemande, par exemple.

Alors quand on voit qu'Azure vient d'ouvrir une région en Pologne...🙄
azure.microsoft.com/fr-fr/updates/…

Et comme on l'a vu, dans l'IT, l'écologie vient souvent de l'économie. Donc est-ce qu'au delà des keynotes, Azure incite, financièrement, ses utilisateurs à privilégier les régions à mix peu carbonés ?

Allons pour cela voir leur grille tarifaire !

Ca se passe donc ici: azure.microsoft.com/en-us/pricing/…

On va sélectionner un type de serveur assez standard, et commencer par regarder son prix mensuel en France.

Et là...tiens, dès que je sélectionne "France Central", j'ai cette bulle qui s'affiche:

Mais où se situe donc cette région "North Europe" qui me permettrait d'économiser quelques biffetons ?

Allons voir sur la page dédiée: azure.microsoft.com/en-us/explore/…

C'est donc...tiens l'Irlande ! Et accessoirement, c'est aussi la plus ancienne région européenne.

Et donc côté mix électrique, l'Irlande et la France se comparent comment en 2022 déjà ? Pour le fun on va aussi prendre la Norvège (Oslo) pour son mix imbattable, et l'Allemagne, pour la raison opposée:

Azure nous recommande donc, et nous incite financièrement, à héberger nos ressources dans un mix 4x plus carboné que le mix français.

Allons voir de quel ordre sont ces économies:

On économise donc 4,5% sur la facture en multipliant par 4 notre intensité carbone, tandis qu'il nous coûtera 15% de plus d'héberger nos ressources dans le mix le moins carboné d'Europe !

Notons toutefois qu'on est pas incité à aller en Irlande quand on sélectionne la Norvège 🤷‍♂️

Je ne veux pas enfoncer Microsoft, d'autant que les gens qui développent cet opérateur carbon-aware doivent être bien loin du business, mais on est bien sur un outil qui n'aura qu'un impact marginal, alors qu'une politique tarifaire guidée par le carbone aurait un impact majeur.

Notez aussi que j'ai détaillé l'offre Azure car la keynote était présentée par Microsoft et qu'ils ont développé l'opérateur, mais c'est pareil pour Amazon.

Et si l'Irlande est privilégiée et moins chère, il ne faut pas douter que le seul climat pris en compte soit fiscal.

J'allais mettre Google dans le lot et m'aperçois que:
- Ils n'ont pas de région irlandaise
- Les régions à faible niveau d'émissions sont clairement indiquées: cloud.google.com/sustainability…
- La Belgique (DC à la frontière française) est la région EU la moins chère avec les Pays-Bas.

Désolé pour la longueur du thread mais c'était difficile d'être plus concis.

La keynote complète est visible ici depuis peu:

J'ai attendu qu'elle soit rendue publique pour rédiger le thread.

@jorgefpalma if you read this, please don't take it too negatively.

I know you have the best intention with the operator but I can't pass over the biggest leverages cloud providers have and obviously choose not to use to limit their carbon footprint.

J'ai oublié de préciser mais l'opérateur carbon-aware va chercher ses données par défaut chez Azure, qui les fournit via une API, mais peut également aller les chercher sur @ElectricityMaps notamment.

Un détail qui me revient: les mix électriques ont une saisonnalité, et je ne suis pas certain que beaucoup d'utilisateurs soient prêts à décaler leur jobs de plusieurs mois quand l'hiver sollicite les centrales fossiles h24...