Humeur : La dette technologique 

de | 2017-05-26

Avertissement préliminaire avant de commencer : ce qui suit est une réflexion au débotté n’engageant que l’auteur, le ci-devant Bis2i. C’est une vision honnête mais sûrement partielle de la situation. Si vous avez des remarques voire – horreur ! – un avis différent, n’hésitez pas à vous servir des commentaires. 

L’effigie

Une bonne hygiène dentaire, c'est important. (Affiche du film "The Dentist", créateur d'une vague de phobie vers la fin des années 90)

Une bonne hygiène dentaire, c’est important. (Affiche du film « The Dentist », créateur d’une vague de phobie vers la fin des années 90)

Raisonnement par l’absurde : votre dentiste vient de recevoir un matériel neuf, moderne, moins coûteux. Par contre, il ne sait pas très bien s’en servir, le commercial ne lui ayant laissé que de vagues instructions. Et il ignore s’il y a des précautions à prendre faute d’avoir eu le temps de lire la volumineuse notice qui accompagnait les cartons.

Oh… Et l’anesthésie était une option payante dont il a fait l’économie car il n’en voyait pas l’utilité.

Lui confieriez vous votre dentition ?

 

L’avers

Tout d’abord, un peu de perspective.

Lorsque l’on parle de « dette technologique », on fait référence à ce genre de situation mais transposée à l’informatique.

Le phénomène était déjà latent. Vous avez sans doute connu le cas où, à peine aviez vous maîtrisé une version ou une fonctionnalité qu’une nouvelle version était annoncée, tout aussi révolutionnaire que la précédente (exemple, pour ceux qui l’ont vécu : le passage de Oracle 8 à Oracle 9, avec ses changements dans les conditions de stockage, son spfile et le nouveau découpage de la mémoire).

Mais ce phénomène s’est largement accéléré, depuis un moment charnière que l’on situerait autour de l’émergence des méthodes agiles.

Celles-ci ont progressivement ringardisé les autres méthodes, en tout cas dans l’esprit des dirigeants, vendant le rêve d’un déploiement rapide, sécurisé, avec moins de temps perdu, moins  d’incidents de production et, mécaniquement, des économies substantielles.

On peut retracer une chaîne de cause à effet depuis ce point :

  • Des méthodes « agiles » (Scrum, Lean…)  qui débarrassent enfin les équipes de développement de la lourdeur des projets.
  • … d’où découlent des outils nouveaux et accessibles autorisant un travail plus efficace.
  • … dont les UDD (Usines De Développement), basées sur des gestionnaires de conteners (comme Docker), pouvant être générées à la demande par Ansible, avec des jeux de données représentatifs et de l’activité artificielle.
  • … permettant de tester vite et bien les nouvelles fonctionnalités et limitant le risque de tout faire exploser lors du passage en production.
  • … aboutissant à la disparition (partielle ou totale) des plages de livraisons au profit d’une livraison continue.

Pour des équipes traditionnellement coincées entre la frénésie du marketing, toujours plus « temps réel », et la lourdeur des procédures de changement façon ITIL (qualification, comité de changement, suivi), ce fut sans doute une véritable bouffée d’oxygène.

Logiquement, ces méthodes et ces outils sont arrivés chez les équipes de production…  où elles ont été fraîchement accueillies.

Non parce que les Opérationnels (l’autre moitié de « DevOps ». Celle que trop de gens oublient lorsqu’ils s’en disent adeptes) seraient allergiques au changement mais parce qu’elles représentent l’antithèse de leur travail.

En effet, en production comme dans la Marine, on apprend rapidement que tout ce qui peut aller mal *va* aller mal, et souvent pire. D’où un besoin constant de contrôle, de surveillance et une nette tendance à la paranoïa.

Ouvrir ainsi les éléments sous leur responsabilité à des changements permanents, écrits par d’autres équipes,  sachant qu’ils seront fatalement en première ligne en cas d’incidents et devront les résoudre sans en connaître l’origine, c’est beaucoup leur demander.

Surtout que cela arrive après des années de lutte contre les changements sauvages et les contournements divers imposés par des chefs de projet pressés par leur deadline. Il aurait fallu des gages de confiance de part et d’autre. Des changements d’habitude afin d’assainir les relations entre ces deux domaines complémentaires mais antithétiques.

Après les méthodes et les outils, la troisième vague fut constituée de leurs enfants naturels, c’est à dire les nouveaux produits nés de l’agilité et de l’automatisation. Ces produits qui avaient été conçus dans un esprit de simplicité et de rapidité de déploiement. Sortis des frameworks dernier cri, basés sur des langages repensés et des paradigmes nouveaux.

Finies les périodes de maintenances : tout sera dynamique et idempotent (typiquement le mot qui permet de repérer l’expert du pipeauteur car on l’entend à toutes les sauces. Si vous voulez être dans la première catégorie, sachez qu’il signifie « une opération ayant le même effet qu’elle soit appliquée une ou plusieurs fois »). Terminées, les frustrantes séances de transferts de fichiers et de copies multiples : tout sera centralisé dans des dépôts Git, et sauvegardé avec leurs différentes versions.

Et partagé.

Et, pourquoi pas, « Liké » par vos collègues.

 

Le revers

Ce mélange d’outils plus efficaces et de méthodes favorisant les changements rapides a été renforcé  par l’image des grandes sociétés américaines des nouvelles technologies qui en ont été l’origine et les ont associées à leur succès. Il a favorisé l’émergence d’une multitude de produits répondant chacun à un besoin précis (stockage, analyse, traitement de messages… ), dans des circonstances précises, par une petite équipe. Voire par une seule personne.

Malheureusement, la vitesse actuelle de l’information permet aux petits projets de trouver un écho plus large qu’initialement prévu. De ce coté, la multitude de blogs techniques et celle des réseaux sociaux favorisent les engouements, pour le pire comme pour le meilleur.  Et le tout forme une caisse de résonance portant jusqu’aux oreilles des directeurs qui y voient naturellement une solution à tous leurs problèmes. Surtout que, si vous ne l’aviez pas compris, c’est gratuit.

Et ainsi se retrouve intégré aux grands projets d’évolution des entreprises des produits tout juste finis, sans support, et à l’avenir incertain. Une ligne de plus dans le catalogue de service. Une pierre de plus dans la chaussure des équipes.

Pas de malentendu : il s’agit souvent de produits soigneusement conçus. Mais leurs auteurs n’ont jamais envisagé un tel succès. Et les inconvénients découlant souvent des choix d’architecture sont bien souvent ignorés au profit de leurs avantages. L’exemple typique étant Cassandra dont les remarquables performances en écriture sont possibles par la remise en cause de la consistance obligatoire des données et par de nouvelles règles dans la conception du modèle. Or, dans l’esprit des intervenants « non techniques », c’est une base de données en mieux car toujours disponible.

Et gratuite.

Vous remarquez le terme qui revient souvent ?

La tranche

Tous ces éléments forment un faisceau qui nous ramène en douceur au sujet évoqué dans l’introduction : submergées par chaque nouveau projet qui apporte avec lui ses outils, ses règles et ses technologies, les équipes – développement comme production – tentent de garder la tête hors de l’eau en espérant que la marée reflue et qu’ils reprennent pied.

A l’heure actuelle, il n’est pas rare qu’un projet nécessite des dizaines de composants différents, chacun évoluant à son rythme, parfois  rapide, n’hésitant pas à casser la compatibilité ascendante sous prétexte d’évolution (comment leur donner tort sachant que Python  n’a toujours pas réussi à supprimer sa version 2 après sa transition en version 3. En 2008. Presque 10 ans !).

Un exemple tiré de la Vie Réelle : Sur une pâte de Cassandra et de Hadoop, sont étalées plusieurs couches fines de Kafka, de Spark, de micro-services, de Java pur (toujours vaillant alors qu’on le dit mort depuis sa sortie !), de Python (version 2. Ou 3), de Zookeeper et de Schema Registry (pour tenter de tenir tout ça debout). Le tout arrosé de Ansible, Git, Jenkins, Docker et cuit dans un four de machines virtuelles  hyper convergentes type Nutanix. Et accompagnée d’un Linux Centos 7 auquel aucun administrateur n’a été formé, malgré le passage à Systemd – pas un petit changement.

Chaque langage embarque ses gestionnaires de paquets et ses coutumes : « pip » pour Python, « Ant » pour Java, « gem » pour Ruby, des arborescences calquées sur Git pour Go… Le point commun : tous sont très simples lorsque vous avez un accès direct à internet.Et deviennent un casse-tête lorsque vous êtes derrière un proxy, comme c’est le cas en entreprise.

Dans ce tourbillon, aucun cerveau ne peut absorber suffisamment d’informations suffisamment vite. Hélas pour lui se dessine un nouveau théorème :

« Toute personne capable de formuler une réponse semblant intelligente sur un sujet à la mode sera immédiatement promue experte du-dit sujet ».

Et son corolaire :

« …Et donc tenue responsable pour tout ce qui pourrait aller de travers par la suite »

Ce qui ne manquera pas de se produire : poussé par la perspective de payer peu, voire absolument rien  (c’est regrettable mais pour certains, c’est le « free » de « free beer » qui a été retenu de « free software ». Pas celui de « free speech« ), d’échapper aux griffes licencieuses des éditeurs traditionnels et d’avoir des performances fantastiques, les DSI se sont déjà jetés dans la tourmente. « Après tout », se disent-ils,  « cela a bien fonctionné pour Facebook, Spotify, Netflix et consorts. Pourquoi pas pour nous ? ».

A ceux-là, il serait bon de rappeler que les sociétés en question, lorsqu’elles ne sont pas à l’origine du code, n’ont pas hésité à investir des sommes importantes pour s’offrir les services d’experts et se donner les moyens de leurs ambitions.

Si Facebook n’avait pas levé des millions et, surtout, s’ils ne les avaient pas dépensés dans la recherche et développement, ils n’auraient pas eu l’infrastructure nécessaire pour répondre à sa croissance. Si Google n’avait pas recruté autant d’experts, ils n’auraient pas pu concevoir un réseau aussi prodigieusement étendu.

C’est en se donnant un socle technique solide qu’ils ont pu grossir à ce point. Et ils ont cherché à assoir leur position avant de songer à être rentable. Or, ailleurs, c’est la perspective de faire la même chose pour un coût moindre qui tient lieu de motivation.

Alors, évidemment, la dette se creuse. Il n’y a plus d’experts au sens strict (« Un expert est une personne qui a fait toutes les erreurs qui peuvent être faites, dans un domaine étroit », selon Niels Bohr). Un cerveau, aussi intéressé et motivé soit-il, ne peut que gérer un nombre fini de sujets dans un nombre fini d’heures.

En fait d’expert, il s’agit plus d’un jongleur qui se voit lancer de plus en plus de massues. C’est un spectacle superbe lorsqu’elles tournoient toutes dans les airs. Mais quel boucan font-elles en tombant !

Fallait que ça arrive un jour...

Fallait que ça arrive un jour…

 

 

 

 

 

 

 

 

 

 

Des problèmes ? des questions ? Exprimez-vous ! Les commentaires sont ouverts. Coquilles et fautes de grammaires sont notre lot quotidien : signalez-les nous à m.capello@dbsqware.com

 

 

Crédit photos : affiche de « The Dentist », de Brian Yuzna. Et l’inimitable Samuel L. Jackson dans Pulp Fiction, de Q. Tarantino.