Disclaimer (comme disent les juristes)
Avant de commencer, je pense utile de préciser que je parle de GreenIT en connaissance de cause, parce que tellement de sociétés informatique ont mis le terme à toutes les sauces qu’il est malheureusement devenu galvaudé. Je tiens à vous rassurer sur le sérieux de mon intérêt pour l’écologie appliquée à l’informatique…
- Une des principales motivations de mon livre sur la performance en .NET était de diffuser des bonnes pratiques pour réduire le gaspillage de ressources, et au moment de proposer à un gourou d’écrire la préface, je n’ai proposé qu’à deux personnes, dont Eric Mittelette précisément parce qu’il est en charge de GreenIT chez Microsoft.
- Je suis, je pense, plus attentif que la moyenne à consommer le moins possible et de façon responsable : je vais au boulot à vélo 6 mois par an sauf tendinite, je n’ai changé d’ordinateur qu’une fois en 10 ans, j’use mes polaires jusqu’à la corde (mes collègues peuvent témoigner), je roule en hybride, et je fais même mon potager.
- Ma thèse de Master était sur la conception en vue du recyclage et de la fin de vie des produits, et c’était il y a plus de 15 ans, à l’époque où ce n’était pas vraiment à la mode…
C’est quoi, mon souci ?
Le disclaimer étant posé, voici mon souci : je pense que trois des pistes majeures qui nous sont aujourd’hui proposées en tant qu’innovations informatiques peuvent avoir un impact négatif sur la consommation de ressources.
- Le Cloud : le fait de disposer ponctuellement d’énormément de ressources pour un coût équivalent à la possession de moins de machines a bien sûr un intérêt en termes de réduction de parc des sociétés utilisatrices, mais peut également pousser à une surconsommation, par déresponsabilisation (pas d’acte d’achat).
- La programmation asynchrone : le temps de traitement synchrone possède une force de signal pour un utilisateur, en termes de ressources nécessaires à un traitement. L’asynchronisme supprime ce retour.
- Big Data : si vous donnez la possibilité à un analyse de réaliser, en mettant des machines en cluster, des simulations ou des requêtes qui étaient auparavant inutiles car trop longues, il est évident que ces activités vont être de plus en plus sollicitées par celui-ci.
Mais ce qui m’embête le plus, c’est l’effet suivant qu’induit le mélange de ces technologies :
La boucle de rétroaction liant la quantité de ressources à la difficulté perçue du traitement risque à terme de disparaitre. Or, il s’agit d’un des seuls garde-fous sur la consommation de ressources informatiques.
Une image vaut mille mots
Je mesure qu’en mode texte, ce n’est peut-être pas très clair. Du coup, j’ai fait l’effort de faire une petite série de diagrammes. Quand on dit que PowerPoint rend bête, je ne suis pas d’accord… Les bullet points rendent bête. Les transitions graphiques sublimes sur un contenu inexistant rendent bête. Les titres accrocheurs sans explication rationnelle rendent bête. Mais pas l’outil, ni la facilité qu’il procure pour créer un diagramme.
Voici en gros comment se passe la boucle de rétroaction dans une architecture “traditionnelle”, avec un client envoyant une requête à un serveur :
Dans la boucle intérieure, une requête simple provoque une retour rapide. Dans la boucle extérieure, une requête plus complexe provoque un retour plus lent. L’utilisateur reçoit un signal en retour concernant la complexité de ce qu’il demande au serveur, et sera donc vaguement conscient du niveau de ressources nécessaires.
On passe en mode Cloud, avec un cluster de machines dédiées à votre système Big Data :
Vous voyez le problème ? On n’a plus de retour sur la complexité du traitement, car le lissage va se faire sur le nombre de machines. Que le traitement mobilise toutes les ressources du cluster ou une seule table de référence pour répondre, le traitement ne prendra pas fondamentalement plus de temps. L’utilisateur n’a plus de retour intuitif sur la quantité de ressources que son interaction lui a fait consommer.
Et si on va plus loin avec un traitement asynchrone, c’est encore pire :
Là, il se peut carrément que l’utilisateur ne reçoive aucune retour, en fonction du comportement de son logiciel et des notifications associées.
Pourquoi c’est gênant
Dans un monde idéal avec des développements performants et des niveaux de consommation rationnels, l’absence de la boucle de rétroaction (l’utilisateur utilise moins de ressources, car il se rend compte que les actions sont lentes et tend à les économiser) ne serait pas si gênante.
Mais à part dans des cas très particuliers, les développements sont rarement optimaux du point de vue de l’utilisation des ressources (avez-vous déjà discuté plus d’une heure avec un utilisateur sans qu’il se plaigne de la performance de votre application ?).
De plus, le manque de retour favorise une consommation surélevée de la ressource. Prenons l’exemple du courrier électronique. J’avoue le premier ne pas faire attention aux nombre de mails que j’expédie. Le fait que l’envoi soit quasi-immédiat et que nous n’ayons aucun retour sur la complexité de faire transiter cette donnée de l’autre côté de la planète y est pour quelque chose. Si les mails avaient un coût direct, et pas seulement un coût indirect par l’abonnement, même très léger, nous n’en enverrions certainement pas autant. Imaginez que vous payiez un forfait à EDF… seriez-vous aussi attentifs à ne pas laisser les lumières derrière vous ?
Pour le Cloud et Big Data, c’est la même problématique : une interaction métier avec un serveur peut très bien mobiliser un cluster de 64 machines sans que vous en soyez conscient. Peut-être imaginerez-vous même qu’il ne s’agit que d’une requête à une base de données. De la même manière qu’un développeur appelle souvent de bonne fois une méthode dans une boucle sans s’être rendu compte que cette méthode appelait un service web… Et l’asynchronisme achève de rendre ceci transparent.
Conclusion
Pour autant, tout n’est pas noir. Il ne faut pas nier non plus que le fait de grouper des traitements dans des sites spécialisés, avec un refroidissement unifié ou encore mieux réalisé de manière passive (comme le fait OVH, ou avec des datacenters en environnements polaires) permet de réduire le coût énergétique global, et d’optimiser les ressources de construction des matériels.
L’approche Big Data, quant à elle, peut permettre d’avoir accès à des analyses qui auraient sinon été réalisées de toute manière à grand renfort de CPU sur plusieurs heures, voire plusieurs journées de traitement.
Enfin, l’asynchronisme est une des méthodes possibles pour favoriser le parallélisme et donc une meilleure utilisation des ressources.
Mais il ne faut pas oublier que, au delà de tous les efforts qui sont réalisés sur la réduction de la consommation sur une base fixe de traitements à réaliser, le mieux est encore de réduire au maximum les traitements à la source. Monsieur Ourghanlian, j’adore vos analyses, votre capacité à les expliquer et surtout votre ouverture sur des domaines autre que l’informatique, mais dans cet article, vous ne parlez à aucun moment du code, alors que c’est la racine du GreenIT !
Coder pour la performance dès le début est extraordinairement important, car cela influe sur tous les niveaux de la chaîne :
Il en va de même pour ces nouvelles approches architecturelles : avant de déployer des solutions qui empêchent toute conscience par un utilisateur de l’impact de ses actions, il convient de se poser la question si des approches plus légères ne seraient pas suffisantes, quitte à ce que l’utilisateur final patiente un peu, affine ses analyses avant de les faire tourner. Bref, l’aider à avoir un comportement plus écologiquement responsable.
Sur ce… je mets en veille j’éteins mon ordi 
