03/04/2019

Impact énergétique des applications WEB. Code optimisé = Impact énergétique maîtrisé !

Le développement d'une nouvelle solution logicielle commence souvent par le codage rapide, en utilisant un framework web, du produit minimum viable (MVP). Une fois ce noyau de base en place, on développe ensuite, au pas de charge (le business n'attend pas) de nouvelles fonctionnalités qui viennent étendre le domaine d'action de cette solution.

Les mois passent et les volumes augmentent, la solution atteint enfin son rythme de croisière. On commence alors à souffler et à prendre un peu de recul mais de nouvelles préoccupations se font jour; les temps de réponses s'allongent, la consommation mémoire est impressionnante et la bande passante est bien remplie et les CPU aux taquets.

Comme du coté business, tout va bien, la prod tourne à fond, les transactions sont assurées et tout le monde est content. Ce n'est surtout pas le moment d'y toucher !

Mais coté environnemental, c'est la catastrophe ; le serveur est une vraie chaudière et son exploitation coûte de plus en plus cher.

Le "Time to market" accéléré offert par un framework comme Ruby on Rails, et un codage rapide ont des effets de bords qui deviennent vite préoccupants.

Mais voir conscience de la consommation énergétique d'un serveur dans le cloud est difficile car les indicateurs proposés sont généralement le temps CPU, la mémoire, les disques. Ils fournissent les métrics clés mais hélas pas d'indicateur de température ou de sa consommation en kWh. Dommage !

Dommage car un code optimisé, une stack performante, une bonne séparation des domaines entre le client et le serveur permettent de soulager la machine, de mieux satisfaire les utilisateurs et de faire baisser l'impact environnemental de la solution.

Une étude, en date du début 2019, révèle les langages les plus voraces en énergie.

Et les résultats ne sont pas beaux à voir pour les langages WEB et tout particulièrement pour Ruby. Pensez que, d'après cette étude, un même code est 70 fois moins performant en Ruby qu'écrit en C et qu'il occupe 60 fois plus de place en mémoire... Imaginez ce que ça peut donner quand le code n'est pas optimisé !

Les développeurs Ruby ayants déjà été confrontés à ces problématiques connaissent l'ouvrage "Ruby Performance Optimization" d'Alexander Dymo , c'est un must read !