Comment le Trade Ledger australien a construit son logiciel basé sur le cloud

Lorsque Martin McCann et Mathias Born ont décidé de créer Trade Ledger, une plateforme de prêt australienne, leur plan était de simplifier et de rationaliser les services de prêt grâce à un logiciel basé sur le cloud pour les prêteurs. Leur parcours fournit des informations aux DSI dans leurs propres efforts de développement.

Lorsque Trade Ledger a commencé à développer son logiciel en tant que service, l'équipe de Born s'est concentrée sur la manière de construire et d'architecturer un système qui ne serait pas obsolète dans quelques années. Au-delà des choix techniques, Born a dû se demander si toute l'équipe travaillait indépendamment sur chaque élément de fonctionnalité, et gérait et entretenait ses parties de ce référentiel.

Et, enfin, dans un contexte commercial, dit Born, il est important de savoir si la fonctionnalité est modulaire et peut être utilisée dans différents domaines.

« C'est parfois plus un art qu'une science. Mais décomposer ces composants dans le bon contexte était définitivement un défi », dit-il.

Les enjeux de la construction de fonctions modulaires et de l'adoption d'une architecture microservices

L'approche d'adoption d'une architecture de microservices s'est heurtée à de nombreux défis.

Pour les organisations qui construisent un système similaire, Born dit qu'il est important de déterminer si certaines parties du système sont très utilisées et de les découpler afin que la fonction puisse ensuite être mise à l'échelle indépendamment.

L'un des défis techniques était que de nombreux ingénieurs de Trade Ledger étaient plus familiarisés avec le SQL traditionnel, les bases de données relationnelles traditionnelles et une manière traditionnelle de construire des modèles de données. « Regrouper tout cela dans la base de données orientée document est certainement une façon de penser différente, mais néanmoins la base de données orientée document était le bon modèle pour nous », déclare Born.

Un autre défi a impliqué une décision précoce de construire le système de manière monolithique. La première version de Trade Ledger qui a été mise sur le marché en 2017 a été construite par une équipe de trois ingénieurs, bien qu'il s'agisse d'un système plus grand et complexe que ce qui existe actuellement. Cette approche monolithique a rendu difficile l'évolution de la plate-forme. Trade Ledger a donc dû passer à une approche modulaire par composants.

En conséquence, ils ont dû décomposer les composants des modules en composants individuels lors de la prochaine itération. Pour ce faire, Trade Ledger a adopté une approche progressive en refactorisant certaines parties du système et en créant des composants dédiés.

Par exemple, Trade Ledger avait initialement une fonctionnalité qui permettait une connexion avec des systèmes de comptabilité basés sur le cloud comme Xero. Désormais, il réside dans son propre composant dédié, plutôt que d'être une fonction au sein d'une application monolithique. "Nous avons pris cette pièce et l'avons déplacée dans son propre composant de connecteur, ce qui nous a ensuite permis de l'étendre indépendamment de tout autre changement dans le monolithe initial", explique Born.

L'architecture de l'application elle-même doit être modulaire, pas simplement les composants codés, note Born. « Dans un système basé sur des microservices, nous voulons nous assurer que les services fonctionnent indépendamment les uns des autres. Sinon, nous risquons de construire une application monolithique en utilisant une architecture de microservices. »

Dans une application modulaire de microservices, une incohérence temporaire est attendue et il est important de s'assurer que les données seront néanmoins essentiellement cohérentes, car les données des différents services peuvent se trouver à différents niveaux en fonction du temps d'exécution.

« D'autres défis consistent à tirer parti de la puissance de la pensée axée sur les documents », déclare Born. « Dans les bases de données relationnelles, les données sont généralement liées entre elles et vous créez des jointures pour interroger ou consolider les données. Dans une base de données orientée document, vous devez penser différemment et pouvez stocker de nombreuses informations dans un objet intégré. Cependant, s'il s'agit d'informations qui changent très fréquemment, ce n'est peut-être pas la meilleure approche pour tout stocker dans un seul document. Plusieurs documents plus petits peuvent être plus efficaces. »

Born suggère quelques éléments à surveiller :

• Si les données appartiennent au même domaine (conception pilotée par le domaine) et que la fréquence des modifications est la même, mettez tout dans le même modèle.
• Si une entité peut vivre sans l'autre entité, placez-les dans deux documents distincts.
• Si une entité nécessite toujours une autre entité spécifique – une relation un-à-plusieurs – il y a de fortes chances que vous puissiez les incorporer dans le même document.

Comment Trade Ledger a pris le contrôle des données

Pour les données elles-mêmes, Trade Ledger a opté pour une base de données orientée documents, qui permettrait la flexibilité nécessaire dans le modèle de données et la capacité de gérer la croissance et l'évolutivité futures.

L'étape suivante consistait à identifier les bons composants qui seraient intégrés dans un système basé sur des composants. «La façon dont nous l'avons construit est que chaque composant possède sa propre structure de données et ses propres tables de données, de sorte qu'un composant ne peut pas parler directement à la base de données de l'autre composant. Tout cela est géré soit par des événements, soit par des API, et cela nous permettra à l'avenir d'avoir de la flexibilité », déclare Born. Cette structure permet à Trade Ledger une séparation claire de la propriété des données dont le composant peut modifier les données.

Avec MongoDB Atlas, le service de base de données hébergé dans le cloud de MongoDB, Trade Ledger a pu configurer sa base de données pour fournir une haute résilience et une haute disponibilité à ses clients, MongoDB fonctionnant comme une couche de données.

« MongoDB est la base de données opérationnelle qui se cache derrière les microservices, et elle nous a fourni la flexibilité nécessaire pour faire le pas. Bien que tous les services n'aient pas leur propre cluster, ce modèle nous donne la flexibilité, si nécessaire, de modifier les services ou les composants qui alimentent les microservices – y compris la base de données – pour prendre en charge différents cas d'utilisation », déclare Born.

La base de données a également aidé Trade Ledger sur le plan opérationnel, car l'organisation a pu décharger une grande partie des activités opérationnelles pour se concentrer ensuite sur les problèmes spécifiques au domaine. Désormais, Trade Ledger peut contrôler où les données sont hébergées, les répliquer, configurer la disponibilité et exécuter des tests. Born dit qu'il y a 10 ans, il aurait eu besoin d'une équipe de 10 à 20 personnes pour faire ce travail.

Choisir les bons outils et langages de programmation

Quant à savoir comment MongoDB est devenu le choix final, Born dit qu'il a examiné des offres comme ArangoDB et DynamoDB, ainsi que quelques options plus petites. L'un des principaux différenciateurs était que MongoDB Atlas fournit une plate-forme hébergée entièrement gérée. « Cela nous a permis de gérer le système de base de données beaucoup plus efficacement, avec une petite équipe », dit-il.

Lorsque Trade Ledger sélectionnait des outils et des langages de programmation, il a commencé par examiner les capacités de base de son équipe d'ingénieurs, qui étaient principalement basées sur Java, et a donc commencé à créer les premiers composants en Java.

Pour son serveur d'événements, Trade Ledger a choisiNATcomme l'un des composants de base pour le bus d'événements, au lieu deApache Kafka . « À l'époque, il n'existait pas de solution Kafka hébergée de qualité sur le marché, et nous n'avions pas suffisamment de capacité pour que plusieurs ingénieurs travaillent uniquement sur Kafka. NATS était une excellente solution qui a optimisé Docker et nous a permis d'être opérationnels rapidement, tout en offrant une solution de messagerie d'événements très robuste. »

Comment Trade Ledger envisage de simplifier son système

Next for Trade Ledger est un changement complet de son expérience utilisateur. Born dit que pour garantir que le système puisse continuer à se développer, un grand changement doit être apporté. Comme l'équipe elle-même en a fait l'expérience lorsqu'elle traverse une phase de mise à l'échelle importante, il est de plus en plus difficile de coordonner toutes les pièces mobiles.

L'équipe d'ingénieurs étudie les principes des systèmes de conception, qu'ils ont commencé à élaborer il y a deux ans, mais l'approche était trop complexe. L'objectif est maintenant de simplifier.

"Ma conviction profonde est que le meilleur code que vous puissiez avoir estpas de code , car vous n'avez pas besoin d'entretien et rien ne peut mal tourner. Évidemment, cela le pousse à l'extrême, mais il s'agit de prendre des décisions intelligentes sur ce que vous codez. C'est l'un des grands apprentissages qui accordent parfois plus d'attention au fait qu'il faut probablement beaucoup moins de temps pour créer un système avec moins de code plutôt que de simplement le coder et créer beaucoup d'informations », déclare Born.

Trade Ledger construit maintenant une solution sans code pour les clients où ils peuvent mettre en œuvre leurs propres règles sans avoir besoin de codage. Born dit qu'il existe des mouvements intéressants autour des plates-formes d'interface utilisateur sans code avec des concepts puissants, mais qu'il reste à prouver si elles fonctionnent aussi bien dans des systèmes plus complexes.