Le mille-feuille empoisonné

Cette semaine, j'assistais à une présentation de la solution Rancher et j'étais à nouveau pris de ce curieux vertige. On monte encore d'un étage. En réalité j'avais déjà visité certains des étages construits au dessus de Kubernetes avec Istio ou Helm. Le temps ne me semble pourtant pas si loin où K8s m'était présenté pour la première fois. Ce devait pourtant être le penthouse. On m'avait alors promis que tous les problèmes de déploiement de Docker seraient ainsi résolus. Mais Docker lui-même n'avait-il pas été annoncé comme la solution miracle venant pallier les "overheads" d'utilisation de ressources induites par la multiplication des machines virtuelles ? Chaque solution, annoncée comme le stade ultime d'une évolution dans le déploiement, semble condamnée à n'être qu'un pharmakon, portant simultanément le remède à un problème et le germe d'une nouvelle difficulté. Mais comme un insecte attiré par une ampoule brillant dans la nuit, nos regards ne parviennent à se détacher de la prochaine technologie miracle qui promet de venir parachever l'édifice virtuel.

Tournons les yeux un moment, et prenons le temps de regarder le chemin parcouru et demandons-nous si la voie empruntée est la bonne. Qu'on ne se méprenne pas, cette invitation à la pause n'est pas une invitation inconditionnelle à rebrousser chemin. Je suis le premier à insister, à l'occasion des sessions de Clean Design que j'anime avec mes collègues de Capgemini, sur l'importance de la réutilisation logicielle dans la conception de nos solutions. Lorsque je démarrais ma carrière il y a plus de vingt ans, mon dossier des logiciels réutilisés ne comptait que trois références. Aujourd'hui, le plus simple des projets présente un dossier comptant une vingtaine de références de premier niveau, et des centaines voire des milliers si on compte les dépendances indirectes. Là où mon premier projet pouvait se résumer à un serveur, un système d'exploitation, quelques librairies et une application, les solutions actuelles s'appuient sur un empilement complexe de matériels, systèmes d'exploitation, machines virtuelles, conteneurs, frameworks, librairies, serveurs d'application et composants métier. S'interdire dans l'absolu le recours à cet empilement technologique serait déraisonnable d'un point de vue économique. Mais l'acceptation de cette dimension de nos métiers ne doit pas pour autant nous dispenser d'une certaine modération.

Les raisons pour lesquelles j'invite aussi mes collègues à cette modération résident dans les risques qu'une réutilisation logicielle peut faire porter sur un projet. Le risque peut être légal (non-respect des obligations induites par une licence ou d'une réglementation locale ou internationale), technique (contraintes d'intégration intrusives ou défaillances logicielles) ou organisationnel (pérennité ou SLA incompatibles avec les exigences du projet). Mais l'empilement technologique auquel je fais référence dans cet article induit un autre problème qui doit être considéré avec attention: l'impact environnemental. Les fournisseurs des couches de ce mille-feuille au carbone ne lésinent certainement pas pour minimiser leur empreinte sur les ressources matérielle, mais elles ne peuvent pas être neutres. Et cet empilement est aussi une addition de coûts environnementaux plus ou moins manifestes.

Pourquoi consent-on à ces coûts ? En matière de dématérialisation la disponibilité, la réactivité et la résistance au facteur d'échelle sont des arguments souvent invoqués. Modularité, couplage faible et cohésion forte justifient le recours presque systématique aux architecture micro-services et à la dockerisation. On ne prête même plus attention aux arguments de portabilité qui ont permis à Java et Python (et JavaScript pour le front) de supplanter les langages historiques tels que le C. Mais ces indiscutables vertus ne cachent-elles pas aussi nos vices ? Le besoin d'une haute disponibilité de certains services ou d'une réactivité systématique sous la seconde ne serait-il pas un caprice de consommateur ? La recherche d'une modularité par l'adoption d'une architecture en micro-services ne révèle-t-elle pas notre incapacité à concevoir un monolithe modulaire (cf. Simon Brown - if you can’t build a well-structured monolith, what makes you think microservices is the answer?) ? Et la virtualisation, la conteneurisation, voire le recours à des langages interprétés, ne démontrent-ils pas un abandon dans la conception de solutions portables ? Quand nous faisons objectivement le point, nous ne pouvons qu'admettre que nos choix techniques ne sont pas toujours justifiés, toujours ajustés au juste besoin. Nous n'avons en effet pas tous l'opportunité de développer le prochain Netflix, Spotify ou Google Search. Et dans bien des situations, l'empilement des couches logicielles est démesuré.

Le prix à payer pour ce mille-feuille, entre les couches desquelles se cachent nos caprices de consommateurs, nos lâchetés de concepteurs, nos incompétences de développeurs, est certainement bien lourd si on l'évalue du point de vue de l'impact environnemental. Il est urgent d'ajouter à la liste des qualités des systèmes que nous concevons, le critère de "frugalité". C'est ce critère qui, dans notre ascension vers la nouvelle technologie à la mode, viendra nous chuchoter "En as-tu vraiment besoin ?"

Comments

[Guilhem Bonnefille]

Humh... sous cet article se cache aux moins deux problématiques qui ne sont pas aussi couplées qu'on pourrait le croire.
D'abord, la frugalité... avant d'être un problème d'architecte, c'est celle du consommateur. Au cours de ma carrière, j'ai été effaré de constater qu'on faisait et refaisait sans cesse la même solution, simplement car le cahier des charges incluait un changement aux apparences mineures, mais qui empêchait la réutilisation de la solution précédente.
Ensuite, il y a la réflexion sur les solutions actuelles. Forcément, sur le plan marketing elles sont présentées comme la réponse à tous les problèmes. Mais avec l'expérience, on ne peut pas se faire embobiner si facilement. Et donc on creuse, on se questionne... et on constate que ces solutions apportent autant de solutions que d'inconvénients, mais viennent adresser des problématiques actuelles. Les langages de haut niveau tentent, depuis toujours, de pallier au manque de standardisation des environnements d'exécution : les travers de la saine concurrence. Les architectures à base de container s'engagent dans la même veine, en permettant de s'abstreindre toujours plus des détails de l'environnement et standardiser toujours plus l'opération de déploiement.

Bref, il y a toujours un revers à une médaille, il faut donc en rester conscient pour faire des choix éclairés.

[Sébastien Dinot]

J'ai toujours apprécié l'idée de frugalité (et d'efficacité) en matière de logiciel et d'architecture. Mais les architectes et les devops « ni dev, ni ops », ne savent que jouer la carte de la surenchère technologique. Il y a une vingtaine d'années, un collègue, visionnaire à sa façon, m'avait dit « je m'en fiche si mon application est bien moins performante que la tienne, s'il le faut, j'utiliserai dix fois plus de machines et mon application fournira le résultat plus rapidement que la tienne ! » À l'époque, sa réponse m'avait choqué : je ne concevais pas qu'on puisse tenir un tel discours sachant ce que coutait une machine, son hébergement, son fonctionnement et son refroidissement. Pourtant, c'est bien son approche orgiaque qui l'a emporté sur l'approche frugale. La frugalité demande un temps, une réflexion, des compétences, que l'industrie ne semble pas avoir, alors elle remplace la qualité par la quantité.