Revue du Technology Radar ThoughtWorks April 2021

Êtes-vous familier avec le paradoxe de la Reine Rouge tiré du livre « Alice au pays des Merveilles » de Lewis Carroll ? La reine nous apprend qu’il faut courir pour rester au même endroit, et courir au moins deux fois plus vite si l’on veut avancer. Pourtant ce paradoxe illustre parfaitement le monde informatique évoluant à un rythme effréné : en l’absence d’une stratégie efficace pour tirer profit des évolutions technologiques, on risque de devenir dépassé puis obsolète.

Pour faire de la veille techno, il ne suffit malheureusement pas de s‘abonner à quelques blogs ou magazines et de les lire pendant le café du matin. On risque d’être submergé par les dizaines d’annonces quotidiennes sur HackerNews au sujet des nouveaux frameworks JS ou des outils Kubernetes.

En tout cas il faut éviter de tomber dans le Buzzword Driven Development: utiliser des technologies dernier cri sans avoir le recul nécessaire ; on n’utilise pas juste parce que c’est nouveau et que ça a l’air cool.

Le Technology Radar propose un cadre intéressant pour initier un processus de veille périodique. Publié deux fois par an par ThoughtWorks depuis 2010, cette analyse reste une référence des technologies et pratiques mises en œuvre dans des projets réels.

Ce radar technologique consiste à afficher sous forme de blips (signaux) les choses qui ont attiré l’attention depuis la dernière analyse. Les blips sont séparés en 4 catégories : Techniques, Tools, Platforms, et Languages & Frameworks. De plus, la position par rapport au centre du radar permet de caractériser les risques et les avantages comme suit :

• Adopt : À utiliser sans hésitation en raison de la maturité et des avantages.
• Trial : À tester car il y a des avantages visibles et peu de risque pour le moment.
• Assess : À explorer dans des projets à bas risque pour bien qualifier son impact.
• Hold : À utiliser avec précaution, le risque est très élevé.

Nous partageons ici notre analyse chez Leanovia du Technology Radar d’avril 2021 en se focalisant sur les problématiques et opportunités souvent rencontrées chez nos clients. Les thèmes de cette édition sont :

Platform Team: Une équipe spécialisée et dédiée à la création et au support des pratiques comme le Continuous Delivery, Modern Observability, Identity and Access Management. Le but est de confier ces activités transverses à une équipe experte afin d’accélérer le développement des fonctionnalités métier.

Consolidates convenience over best in class: Utiliser une plateforme consolidée comme GitHub ou Azure DevOps au lieu d’intégrer manuellement des outils comme le gestionnaire de versions, le wiki ou les pipelines CI/CD, etc. L’idée est de privilégier le côté pratique plutôt que de mettre son énergie dans l’intégration d’outils même si ces derniers offrent parfois plus de fonctionnalités.

Discerning the context for Architectural Coupling: À chaque fois que l’on fait communiquer deux composants logiciels, par exemple des classes ou des microservices, la question se pose : Quel est le bon niveau de couplage ?
Il n’y a pas de réponse unique ni de solution miracle. Il faut considérer les exigences en terme d’intégration et de maintenance des composants dès la définition de l’architecture.

Techniques

Adopt

API expand-contract or Parallel Change: Une technique en trois phases pour gérer l’évolution des API sans interruption de service ni impact pour les clients. Dans la phase expand, l’interface évolue afin de d’intégrer la nouvelle version de l’API mais les utilisateurs continuent d’utiliser l’ancienne version.

Dans la phase migrate, les deux versions tournent en parallèle et les utilisateurs vont migrer progressivement vers la nouvelle. Enfin, dans la phase contract, l’ancienne version est supprimée une fois tous les utilisateurs passés sur la nouvelle version de l’API.

Cette approche d’évolution technique minimisant l’impact pour les utilisateurs est universelle et peut être appliquée pour la migration des schémas de base de données ou d’autres composants. La description complète peut être trouvée dans le chapitre Handling Versions du livre « Release It » de Michael Nygard dont nous conseillons vivement la lecture !

Hold

Naive Password Complexity Requirements : Nous constatons toujours des politiques de mot de passe assez complexes : combinaisons des majuscules, chiffres, caractères non alphanumériques. Parfois ces politiques frôlent l’absurde. Cela induit une fausse sensation de sécurité en plus d’être une source constante d’agacement pour les utilisateurs qui sont obligés de suivre ces stratégies.
La préconisation du NIST, National Institute of Standards and Technologies, est de privilégier la longueur comme seul mécanisme efficace d’amélioration de la robustesse du mot de passe. On parle même d’utiliser des phrases complètes plutôt qu’un mot complexe afin de faciliter la vie à l’utilisateur.

SAFe : Les méthodes agiles sont nées du besoin de simplifier le processus de développement logiciel afin de livrer plus rapidement, plus souvent et en accord avec les besoins métiers. La tendance de l’industrie à uniformiser et créer des systèmes a fait apparaître des frameworks, comme SAFe, inspirés des méthodes agiles mais adaptés à l’échelle de l’entreprise.

Notre avis est que ces frameworks vont à l’encontre du principe même d’agilité qui visait une meilleure collaboration entre les équipes (“Individuals and interactions over processes and tools”). Malgré le langage moderne cela devient presque aussi rigide que les méthodes classiques de gestion de projet en cascade ou en cycles en V.

Separate code and pipeline ownership: ThoughtWorks conseille dans ce cas de ne pas séparer les équipes dédiées au développement et les équipes qui gèrent la pipeline de déploiement. L’objectif affiché étant d’éviter la création des silos.

Cette préconisation nous semble en contradiction avec le thème Platform Teams abordé plus haut où ThoughtWorks conseille de confier ces activités transverses à une équipe experte et dédiée.

Quelle est la bonne solution? Comme pour la question du bon niveau du couplage dans une architecture, la réponse est probablement: ça dépend, à affiner en fonction du contexte.

Platforms

Assess

Kafka without Kafka et RedPanda : Malgré l’évidente puissance et popularité d’Apache Kafka dans le domaine de la messagerie et du streaming, l’installation et la maintenance restent complexes. Apparaît alors une idée intéressante : « Et si l’on pouvait bénéficier de l’API et du protocole Kafka avec des outils simples? » RedPanda, qui d’ailleurs ne nécessite pas d’utiliser ZooKeeper, est une alternative à explorer.

Opstrace : Une solution open source du fondateur de dotCloud, précurseur de Docker, qui promet d’intégrer des métriques (Prometheus) et logs (Loki) pour faire du monitoring (ou observability).

ThoughtWorks le positionne comme une alternative à des outils payants leaders su marché comme Datadog et Dynatrace. Selon nous, il manque encore des fonctionnalités comme le tracing (Jaeger) ou l’expérience utilisateur (Matomo).

Tools

Trial

k6 : En Assess lors du dernier Radar, cet outil de test de charge écrit en Go (pour la puissance) devient de plus en plus attractif en raison du langage de scripting (JavaScript) et de la facilité d’intégration avec des backends de visualisation. Nous partagerons prochainement dans un article dédié le résultat de notre comparatif avec des outils plus connus comme Gatling et Locust.

Assess

Buildah et Podman : De notre point de vue ces outils appartiennent à la catégorie Adopt. Nous les utilisons en production dans nos clusters OpenShift et les avantages sont indéniables : moteur daemonless, rootless par défaut, compatibilité avec la syntaxe Docker pour Podman et support pour OCI (Open Containers Initiative).

Languages and Frameworks

Adopt

Leak Canary : Librairie Android qui permet d’identifier des fuites mémoire sur des applications mobiles. Selon nous, bien qu’elle n’offre pas toutes les fonctionnalités d’un agent APM, elle est en revanche très simple à intégrer.

Assess

Flutter for Web: Nous avons développé des applications mobiles avec Flutter et nous confirmons que la gestion de deux codebases, web et mobile, est un besoin courant.

La dernière version de Flutter permet de répondre à ce besoin de rationalisation. Cependant la migration n’est pas intuitive de prime abord : l’application Flutter (écrite en Dart) est compilée en JavaScript puis affichée avec deux types de renderer, HTML ou CanvasKit.

Nous partagerons prochainement dans un article dédié notre retour d’expérience sur le sujet.

Conclusion

Comme à son habitude, ThoughtWorks présente son avis par rapport à des idées parfois à la frontière de l’innovation. Même si nous ne partageons pas forcément toutes les conclusions, dans cette édition, nous nous sommes intéressés à :

La réflexion sur l’organisation des équipes: faut-il donner la responsabilité d’une fonctionnalité de bout en bout, ou plutôt concentrer l’expertise technique dans un Platform Team? Comment gérer la charge cognitive ainsi que la communication entre équipes?

La maturité des applications conteneurisées : cette technologie a atteint le plateau de productivité (Hype Cycle de Gartner). Des questions se posent par rapport à la standardisation (Open Application Model), la simplification (Kafka without Kafka), la performance (k6) et l’outillage en général (Buildah, Podman, Operator Framework).