
Maintien et scalabilité d'une application vieille de 20 ans
L'article qui suit est basé sur le talk de Arnaud Lahaxe, architecte applicatif chez Boursorama. À l'occasion de sa présentation, il a évoqué les défis auxquels il a été confronté, ainsi que les stratégies qu'il a choisi d'adopter pour le maintien et la scalabilité d'une application monolithique vieille de 20 ans.

L’état des lieux
Les applications monolithiques ont longtemps dominé le paysage logiciel, fournissant des solutions intégrées et robustes. Cependant, au fil du temps, elles peuvent devenir des fardeaux technologiques, surtout lorsqu'elles atteignent la vingtaine, comme dans le cas de l'application BoursoBank.
Basée sur un framework maison utilisant la stack LAMP (Linux, Apache, MySQL, PHP), l'application contient du code spaghetti difficile à maintenir, une interface étroitement couplée à la logique métier, et une absence de tests et de métriques.
Cette application est cependant de plus en plus sollicitée et le nombre de clients qui l'utilisent ne cesse d'augmenter. Dans ce contexte, une refonte n'est pas envisageable : il faut améliorer l'application sans frozen zone et avancer au fil de l'eau pour l'optimiser. Les défis sont nombreux.
Quels sont les défis majeurs rencontrés ?
Pour maintenir l’application BoursoBank, Arnaud Lahaxe a dû relever plusieurs défis :
- Code spaghetti : il se caractérise par des dépendances complexes et enchevêtrées, rendant toute modification risquée et coûteuse.
- Couplage de l'interface et de la logique métier : une architecture où l'interface utilisateur et la logique métier sont étroitement liées empêche la réutilisation de composants et rend l'application rigide face aux changements. Cela complique également les mises à jour de l'interface utilisateur, nécessitant des modifications étendues dans le code métier.
(Source : Slides de présentation de Arnaud Lahaxe)
- Absence de tests : sans tests unitaires ou fonctionnels, il est difficile de garantir que les modifications n'introduisent pas de nouvelles erreurs. Cette situation ralentit considérablement le développement et la correction des bugs.
- Absence de métriques : Sans métriques de performance et de qualité, il est impossible de surveiller l'état de l'application ou d'identifier les goulots d'étranglement. L'optimisation et la scalabilité deviennent des tâches hasardeuses et inefficaces.
Quelles stratégies de maintien mettre en place ?
Refactorisation progressive et découplage de l'interface et de la logique métier
Une approche itérative permet de réécrire progressivement des parties du code, en commençant par adresser les problèmes les plus critiques.
BoursoBank a choisi de commencer par la création d'une architecture 3 tiers afin de séparer les responsabilités.
- Un front : il est stateless, n'a pas d'accès aux données ni aux partenaires et est client de l'API ;
- Une API : elle est créée à partir de l'application monolithique de départ. Elle ne contient pas d'UI et est migrée sur des composants Symfony. Elle introduit l'utilisation de services pour la logique métier ;
- Une partie données et partenaires.
(Source : Slides de présentation de Arnaud Lahaxe)
Mais cette amélioration ne suffit pas, car le front fait trop d'appels à l'API, dont des appels redondants entre les différentes pages de l'application. Les performances du site sont moins bonnes qu'avec le monolithe.
Amélioration des performances
Pour améliorer les performances, la gestion d'un cache HTTP est privilégiée. La mise en cache de différentes données permet :
- une amélioration des performances, les appels API redondants utilisent le cache, réduisant ainsi les temps de réponse ;
- des économies, avec une réduction de la charge sur les serveurs backend et de la consommation de bande passante ;
- une amélioration de la résilience ou de la capacité du système à gérer une charge élevée ou des pics de trafic inattendus en répondant directement à partir du cache ;
- une tolérance à la panne, ce qui maintient la disponibilité du site, même en cas de défaillance des serveurs backend, assurant ainsi une continuité de service.
L'utilisation de Varnish a été choisie pour mettre en œuvre cette stratégie de cache. En effet, Varnish offre une solution de cache HTTP puissante, flexible et efficace, adaptée aux besoins des sites à fort trafic nécessitant des performances élevées et une grande résilience.
Monitoring en continu
Il ne faut pas négliger la surveillance :
- Lors des déploiements, car une mise en place de blocages au niveau de la CI/CD permet de s'assurer que seules les versions stables passent en production ;
- Au niveau du code, puisque le lancement d'analyses de code statique permet de détecter les potentielles failles et optimisations ;
- Avec l'utilisation de Blackfire qui permet de collecter des données sur les ressources serveur consommées (il est alors possible d'utiliser ces données pour identifier les goulots d'étranglement et planifier des améliorations ciblées) ;
- En mettant en place un système de monitoring qui permet de vérifier en continu les performances, d'alerter automatiquement en cas de problème et de suivre diverses métriques essentielles pour maintenir et améliorer la qualité du service.
Accompagnement des équipes
La mise en place d'un accompagnement des équipes est cruciale pour garantir la réussite et la pérennité d'un projet. Cet accompagnement repose sur plusieurs piliers essentiels.
- Une communication régulière : il est fondamental d'établir un flux de communication au sein de l'équipe. Cela inclut des réunions régulières pour discuter des progrès, des défis rencontrés et des solutions potentielles. Une bonne communication permet également de partager les objectifs à court et à long terme, assurant ainsi que tous les membres de l'équipe sont alignés et travaillent dans la même direction ;
- De la veille technologique : il est crucial de rester informé des nouvelles technologies et des meilleures pratiques. Encourager les membres de l'équipe à participer à des formations, à des conférences et à des ateliers permet non seulement de mettre à jour leurs compétences, mais aussi de découvrir des solutions innovantes pour moderniser l'application et améliorer son efficacité ;
- Des séances de feedbacks après de grosses régressions : les régressions sont inévitables dans la vie d'une application. Organiser des séances de feedback après de telles occurrences est essentiel pour analyser les causes profondes des problèmes, apprendre des erreurs et mettre en place des mesures correctives. Ces séances doivent être constructives et orientées vers l'amélioration continue, favorisant ainsi une culture de transparence et de responsabilisation.
Un accompagnement bien structuré et adapté garantit non seulement la stabilité et la performance de l'application, mais aussi le développement continu des compétences et de la cohésion au sein de l'équipe. En investissant dans un accompagnement solide, les entreprises peuvent assurer la motivation et l'engagement de leurs équipes, tout en favorisant une amélioration constante et une adaptation aux évolutions technologiques.
Pour conclure, maintenir et scaler une application vieille de 20 ans est un défi complexe qui nécessite une approche méthodique et stratégique. Pour toute entreprise confrontée à la maintenance d'applications anciennes, les étapes suivies par Boursorama sont cruciales pour garantir la stabilité, la performance et l'évolution continue des systèmes tout en répondant aux exigences croissantes du marché et des utilisateurs.
Vous avez aimé cet article, découvrez d'autres articles rédigés suite à l'AFUP Day 2024 à Nancy :
- Architecture à mettre en place pour un SaaS en fonction du client
- Principes et implémentation d’OpenTelemetry dans des projets PHP
- Game-changing CSS : les techniques pour des sites Web performants
- Container, the hard way : un voyage à travers la complexité des conteneurs
- Comprendre le TDD : principes, architecture hexagonale et types de tests
- Introduction à l’Event Sourcing en PHP
Crédit photo : utah778
