Chez Moneythor, nous nous engageons à fournir une solution technique pouvant être mise en œuvre avec des composants faciles à entretenir, rentables et entièrement alignés sur les normes de l'industrie afin de garantir la longévité et l'évolutivité de nos logiciels.
L'industrie du logiciel a toujours été et continuera d'être sensible à des développements rapides avec la mise en œuvre de nouvelles architectures et des outils rapidement obsolètes, mais elle est également très compétitive à mesure que de nouvelles initiatives sont développées pour établir des différenciateurs clés pour les solutions. Cela est encore plus vrai aujourd’hui, alors que les fournisseurs de cloud investissent massivement dans les logiciels, le matériel et l’infrastructure.
Dans cet environnement en constante évolution, passons en revue ce que nous prenons en compte lorsque nous faisons soigneusement nos choix d'architecture technique et à quoi prêtons-nous attention lors de la construction du La solution Moneythor.
Qu’est-ce que la dette technique ?
Il existe plusieurs interprétations de la dette technique, mais la définition la plus communément acceptée est toute décision prise dans le but d'obtenir des gains rapides même si on le sait implique une refactorisation ou une révision à une étape ultérieure. Dans notre cas, il peut s'agir par exemple d'implémenter un morceau de code parfaitement fonctionnel et non aligné avec la stratégie à long terme du produit, ou de cas extrêmes laissés volontairement de côté en l'absence d'exigences fonctionnelles qui en ont besoin à ce moment-là.
Pourquoi est-ce important pour nous ?
Comme la grande majorité des solutions logicielles d’entreprise, la plate-forme Moneythor repose sur un grand nombre de bibliothèques Open Source. Les logiciels Open Source ont toujours été développés par des particuliers ou financés par des leaders de l'industrie. Aujourd'hui, les grandes organisations contribuent de plus en plus au développement de nombreux projets de logiciels Open Source pour répondre à leurs propres besoins. Pensez au désormais inévitable Apache Kafka (de LinkedIn), Kubernetes (de Google), Réagir (depuis Facebook/Méta) ; la liste s’allonge chaque jour.
Compte tenu de la complexité de la solution Moneythor, il serait inimaginable, extrêmement long et coûteux de construire nous-mêmes tous les aspects de la solution, sans parler du risque de réinventer la roue sans jamais atteindre le même niveau de qualité de ces projets tiers sponsorisés. par des organisations renommées et testé de manière intensive dans plusieurs environnements de production.
Cela dit, la sécurité est une préoccupation majeure. Personne n'aime entendre comment un service a subi une violation de données, mais il est presque impossible d'éviter des vulnérabilités comme celles régulièrement signalées. Vulnérabilités et expositions courantes et nécessitent souvent une action immédiate pour y remédier.
En tant que tel, nous testons et sélectionnons soigneusement toutes les bibliothèques tierces, en considérant toujours les alternatives et la difficulté de comprendre leur code source et de résoudre nous-mêmes les problèmes de sécurité. Cela fait, nous l'intégrons dans notre solution avec les couches nécessaires pour garantir qu'il puisse être facilement mis à niveau ou même remplacé.
Soyez conscient de votre dette technique
Réécrire le code source ou passer d’une technologie à une autre entraîne souvent un coût élevé, difficile à justifier auprès des parties prenantes. C’est pour cette raison que nous prenons en compte la dette technique dès l’origine. La façon dont nous concevons notre solution joue ici un rôle important et parfois, nous n'hésitons pas à déployer un effort supplémentaire initial pour préparer la solution à une fonctionnalité supplémentaire non confirmée.
C'est également l'occasion pour nous d'enregistrer dès le début ce qui sera considéré comme des implémentations finales de nouvelles fonctionnalités et des éléments pour lesquels nous avons dû prendre quelques raccourcis pour produire une solution fonctionnelle à temps, tout en sachant que certaines parties pourraient être revisitées plus tard.
Il est à noter que les exigences fonctionnelles évoluent et que nous devons revoir le code existant. Dans ce cas, nous ne traitons pas d’un poste de dette technique. Il s'agit simplement du cycle de vie naturel d'une solution constamment améliorée.
Maîtriser la dette technique
Cela dit, il est impossible de prédire l’avenir et il est risqué de parier sur une solution ou un mot à la mode à venir. Par exemple, la solution Moneythor s'appuie sur les fondements de la suite d'applications Java Enterprise, une plateforme très mature et respectable qui a soutenu le développement de millions de projets logiciels d'entreprise éprouvés au cours des dernières décennies. L'une des fonctionnalités de la plate-forme Java est la vénérable API Servlet bloquante, un modèle éprouvé différent de l'approche de traitement de flux asynchrone non bloquante promue par la nouvelle initiative de programmation réactive.
Si cette dernière devient l'approche par défaut à l'avenir une fois que la communauté et de nombreuses dépendances auront adopté ce nouveau paradigme de programmation, cela pourrait créer une dette technique où il serait nécessaire d'investir du temps pour apporter une solution à un nouveau standard avec le même niveau de performance. fonctionnalité comme avant.
Dans ce cas, le rôle de l’équipe d’ingénierie est encore une fois de concevoir la solution de telle manière que nous puissions minimiser l’effort de réécriture et d’adaptation des fonctionnalités existantes sans avoir à consacrer du temps à adapter la logique métier existante.
Les systèmes de stockage de données créent facilement une dette technique
Comme chacun le sait, le monde produit et consomme de plus en plus de données chaque année à un rythme exponentiel. Le traitement et l'analyse d'une énorme quantité de données ont toujours été un défi majeur pour les organisations de tous les secteurs, y compris celui des services financiers. Il n’est pas surprenant que l’industrie du logiciel travaille et crée constamment de nouveaux outils visant à résoudre ces défis en constante évolution en matière de données.
Alors que les bases de données relationnelles étaient autrefois la base de données par défaut et que leurs versions gérées dans le cloud sont très évolutives, il existe désormais des approches complètement différentes sur la façon de conserver et d'interroger les données. Passer d'une base de données relationnelle traditionnelle à quelque chose comme un magasin de documents n'est pas aussi simple que de basculer entre deux fournisseurs de bases de données relationnelles différents. Dans de nombreux cas, la solution existante s'appuie sur des principes et des contrats qui n'existent plus dans le nouveau magasin de données.
La dette technique a des conséquences
Notre expérience dans ce secteur au cours des dernières décennies et de multiples projets hétérogènes montrent qu’il existe un seuil au-dessus duquel la dette technique devient un trou noir et ce seuil diminue de plus en plus avec le temps, surtout lorsqu’aucune action n’est entreprise.
Cela signifie ceci : lorsque la limite est atteinte, il peut s'avérer impossible de rattraper votre dette technique, et au final, il vous en coûtera moins cher de tout réécrire à partir de zéro, ce qui peut être un effort important et démoralisant. Lorsque cela se produit, toute l’expérience et les connaissances que vous avez acquises avec une seule technologie doivent être reconstruites.
Par exemple, passer de la populaire base de données relationnelle PostgreSQL au également populaire magasin de documents Mongo DB ne consiste pas seulement à rendre votre logiciel compatible avec les deux couches persistantes. Il s’agit également de comprendre les implications que cela a sur le flux de données, le processus transactionnel, les avantages et les inconvénients des deux solutions, ce que vous obtenez et ce que vous perdez. Cela peut facilement être négligé, entraînant des retards et des coûts supplémentaires, voire des échecs dans certains cas.
Notre approche pour gérer la dette technique
Comme mentionné précédemment, il serait impossible de prévoir les évolutions, et nous ne pouvons pas non plus raisonnablement tout mettre en œuvre d’un seul coup. Ce que nous pouvons faire, c’est essayer de nous protéger contre les obstacles inutiles. Des modèles d’architecture et de conception bien connus et éprouvés existent dans ce but précis.
Premièrement, la solution est construite au-dessus du Cadre de printemps. Le point le plus important à noter ici est que nous avons choisi Spring non seulement parce qu'il est extrêmement populaire, bien entretenu et qu'il fournit un riche ensemble de sous-projets pour aider à aborder de nombreux aspects des solutions logicielles d'entreprise, mais aussi parce qu'à la base, c'est un framework d'injection de dépendances qui nous permet de découpler notre code et facilite grandement la mise en œuvre du séparation des préoccupations principe.
Dans la mesure du possible, nous dissocions tout, des bibliothèques tierces à notre propre code afin que l'implémentation soit facilement remplaçable. Ensuite, une fois que nous décidons d’implémenter une nouvelle fonctionnalité, nous commençons par découpler l’implémentation concrète de la logique métier avec le framework. Nous prenons également plus de temps pour concevoir une couche intermédiaire générique qui se situe entre le cadre technique alimenté par Spring ou des bibliothèques tierces et la mise en œuvre des exigences métier. Le but de cette couche intermédiaire est de fournir une abstraction de l'objet de la fonctionnalité afin que nous puissions ultérieurement la personnaliser facilement et la protéger de l'impact de la mise à niveau ou du remplacement des composants techniques sous-jacents.
Le résultat est que la solution Moneythor devient elle-même un framework avec une implémentation concrète de la logique fonctionnelle, et pas seulement cette implémentation. Cela nous offre une grande flexibilité, ce qui est extrêmement précieux dans notre cas. Cela nous donne également la possibilité de maintenir le même produit pour tous les clients. Bien entendu, nous adaptons notre solution aux différentes régions, environnements cibles et fonctionnalités spécifiques au client mais cela est réalisé grâce à une seule version du code source sans aucun fork.
Aujourd’hui, on peut mesurer les bénéfices de cette approche. Nous avons commencé à développer cette suite d'applications il y a près de 10 ans, et pourtant nous ne conservons aucune bibliothèque vulnérable. Au lieu de cela, nous utilisons la dernière version de Spring et d'autres composants tiers, ce qui nous permet d'ajouter la prise en charge de nouvelles technologies dans les limites du budget et sans avoir besoin de refactoriser une grande partie du logiciel. Enfin et surtout, cela maintient notre équipe de développement motivée à travailler sur une architecture moderne avec des technologies et des outils récents.
Il s'agit essentiellement de trouver le bon équilibre entre une conception et une ingénierie complexes et un coût de retouche acceptable. Avec la solution Moneythor, nous avons réussi à trouver cet équilibre et continuerons de le faire.
