Il ne faut pas croire que les vieux logiciels et leur code tournant sur des mainframes sont obsolètes. Les outils de monitoring – et une bonne documentation – peuvent contribuer à trouver et à résoudre les problèmes qu’ils peuvent éventuellement poser.
On pense souvent, à tort, que les logiciels historiques sont des programmes écrits par d’autres et utilisés par d’autres. « Dès qu’on livre du code, on crée des logiciels hérités », a affirmé Jean Yang, fondatrice et CEO d’Akita Software. « Il y a des choses qui vous lient, qu’on ne peut pas changer. Je ne me souviens pas du code que j’ai créé la semaine dernière, et je pense que c’est vrai pour toute personne qui écrit du code », a-t-elle ajouté. « La plupart du temps, les gens pensent que le « legacy applicatif » sont des programmes écrits en Cobol et stockés quelque part sur un ordinateur central. Cette croyance conduit les développeurs à construire du code en aveugle, sans penser à ceux qui seront amenés à lire ce code plus tard ». Et, comme le souligne encore Jean Yang, cela inclut à peu près tout le monde, y compris le développeur à l’origine du code.
L’un des problèmes du code, c’est qu’il n’est jamais vraiment statique, ni écrit dans le marbre. Comme le fait remarquer Charity Majors, cofondatrice et directrice technique de Honeycomb, dans l’échange qu’elle a eu avec Jean Yang, « chaque fois que le code transite par le réseau, c’est l’inconnu, car on perd tout contrôle sur lui ». C’est comme si l’application naissait dans un jardin d’Eden. Mais pour la rendre utile, il faut passer par un appel réseau. « Et c’est là que tout s’écroule, parce que c’est à ce moment-là qu’on introduit de la complexité dans l’application », a-t-elle ajouté. D’après Charity Majors, il est quasiment impossible de savoir comment va se comporter le logiciel avant qu’il ne soit en production. Ce n’est que dans ce cadre-là que les faiblesses de ce code « hérité » vont se révéler. « Un petit bout de code est un système compliqué, mais quand on le met en production, quand il est exploité par des utilisateurs, quand il suit des modèles de trafic différents et tourne sur une infrastructure sous-jacente différente, il devient complexe », a encore déclaré la CTO de Honeycomb. Complexe, dans le sens où il introduit des « inconnues ». « Il est impossible de prévoir comment va se comporter l’application quand on change un bout de code. Il faut d’abord appliquer le changement et observer ce qui se passe dans un environnement contrôlé », a poursuivi Charity Majors.
Des problèmes humains, pas des problèmes de code
Comme le fait encore remarquer la dirigeante, « des développeurs indépendants peuvent écrire des logiciels, mais seules des équipes peuvent livrer, expédier, maintenir et posséder des logiciels. La plus petite unité de livraison de logiciels, c’est l’équipe ». Mais que veut-elle dire par là exactement ? Jean Yang explique que l’on peut se bercer d’illusions en pensant que les problèmes (bogues, erreurs, etc.) sont des problèmes techniques de l’application. Selon elle, en imaginant cela, on est à côté de la plaque. « C’est toujours un problème de personnes. Il faut toujours faire confiance aux gens. Et la plupart des outils permettent de faire une sorte d’archéologie des pratiques antérieurs, plus ou moins récentes, pour savoir si elles pourraient être à l’origine de ces problèmes ». Ce qui nous ramène à l’héritage. Et à l’observabilité.
« Plus le code est ancien, plus le coût de la recherche et de la correction des problèmes dans les logiciels augmente de façon exponentielle », a déclaré Charity Majors lors de son entretien avec Mme Yang. En tant que tels, les outils de monitoring comme ceux d’Akita ou de Honeycomb peuvent jouer un rôle essentiel pour résoudre les problèmes en quelques minutes. En exécutant le code en production contrôlée, ces outils proposent aux développeurs de déboguer le code hérité peu de temps après son écriture, au lieu d’avoir à le déchiffrer des mois ou des années, voire des décennies plus tard. C’est pour cette raison aussi qu’une bonne documentation est essentielle. On pense parfois que la documentation peut aider les autres à être plus productifs avec le code que l’on a écrit, et c’est tout à fait vrai. Mais, comme l’a expliqué un jour Simon Willison, fondateur de Datasette, il rédige en général cette documentation pour lui-même, car sinon, il oublie pourquoi il a écrit le code de telle manière plutôt que de telle autre. « Si je reviens sur le projet deux mois plus tard, tout fonctionne et je sais où se trouve chaque élément », a-t-il déclaré, parce qu’il avait écrit une documentation détaillée pour l’aider (lui ou quelqu’un d’autre) à se retrouver son chemin dans le code.
Une bonne documentation, de bons tests unitaires et une bonne observabilité
« Une partie du développement consiste à l’exploiter, et à voir comment il se comporte sous différents systèmes et contraintes. On ne peut jamais comprendre un code dans l’IDE », a insisté Mme Majors. Il faut l’exécuter, puis l’observer. Mais qu’en est-il de ceux qui regardent le code écrit par un autre et qui essaient de l’exécuter des années ou des décennies plus tard ? Même pour ceux qui pensent ne pas être concernés par cela, la remarque faite récemment par Avishai Ish-Shalom, Glorified Janitor chez Fewbytes, mérite d’être citée : « Notre infrastructure « moderne » comme Linux, MySQL, PostgreSQL, etc. date de plusieurs décennies, et même nos clouds « modernes » sont encore en pleine adolescence », a-t-il déclaré. Mais, plus inquiétant, il a aussi déclaré : « Cette infrastructure, même si elle se révèle remarquablement plus flexible et stable que nos prévisions les plus optimistes, montre des signes d’usure et de vieillesse, rendant la maintenance et le développement plus difficiles, année après année ».
Qu’il s’agisse d’une dette technique ancienne ou récente, nous vivons tous dans un monde de legacy. Nous passons des environnements monolithiques aux microservices (parfois), nous passons du disque dur à la mémoire flash et nous faisons bien d’autres choses quand nous nous heurtons à des contraintes matérielles ou logicielles, ou quand nous entrevoyons l’opportunité d’exploiter de nouvelles avancées. « Pour ceux qui travaillent avec des systèmes vieux de plusieurs années ou décennies, la situation s’aggrave », a expliqué Jean Yang. « Tous les systèmes construits au cours de l’année écoulée présentent les mêmes caractéristiques, mais tous les systèmes construits il y a 5 ou 10 ans ont vieilli chacun à leur manière… D’une façon ou d’une autre, on peut dire que chaque système est un héritage ».
Rendre la complexité traçable
C’est pour cette raison que les entreprises utilisent Akita pour cartographier les services, comme un outil de découverte. Elles essaient de comprendre ce que font leurs systèmes existants et comment ils fonctionnent. Ces mêmes personnes pourraient aller encore plus loin avec les outils d’observabilité de Honeycomb. Comme l’affirme Charity Majors, « dans les deux cas, ces outils essayent de « rendre la complexité traçable », afin de permettre aux personnes – aux équipes – de comprendre et de délivrer encore plus de logiciels. Certes, elles créent ainsi encore plus de code traditionnel. Mais ce n’est pas grave, tant qu’on utilise des outils d’observabilité pour comprendre et apprivoiser cet héritage. Il n’y a aucun moyen de l’éviter ; il n’y a désormais aucune raison de le vouloir.