Contactez-nous pour un devis FinMV personnalisé et adapté à vos besoins.
Le directeur technique de votre entreprise, lors de la planification du lancement d'une plateforme financière, devra choisir une option d'architecture de projet. Quelles options d'architecture s'offrent à lui et laquelle vaut-il mieux choisir ?
Une architecture monolithique est comme une boule de neige. Vous démarrez un projet et vous faites une petite boule de neige. Il est si petit qu'il peut être développé et roulé par une petite équipe. Quelques années ont passé, et maintenant votre boule de neige est devenue si énorme que 20 développeurs la poussent déjà. Dans quelques années, des centaines de développeurs feront boule de neige avec une tonne de code, mais le lancement de nouvelles fonctionnalités deviendra très lent.
En conséquence, les propriétaires commencent à changer le directeur technique, les membres de l'équipe, mais ça ne fait qu'empirer. Les nouveaux membres de l'équipe ne connaissent pas les détails historiques, pourquoi la boule de neige est telle qu'elle est et pas une autre. La documentation produit devient rapidement obsolète.
Pourquoi ne pas le faire dès le départ ? Premièrement, au tout début d'une entreprise, il y a toujours les ressources sont limitées, il n'y a pas assez de développeurs, d'expertise et de temps. Le manuel est pressant et les programmeurs sont pressés de le faire de la manière la plus rapide possible.
Deuxièmement, les ingénieurs techniques pensent : "Eh bien, que ce soit une architecture monolithique pour l'instant, mais quand l'entreprise grandira, alors nous allons tout refaire". Malheureusement, en réalité, transférer un projet monolithique existant vers une architecture de microservice sera dix fois plus difficile que de tout écrire à partir de rien.
Nous rendrons votre plate-forme financière immédiatement basée sur une architecture de microservices.
L'architecture des microservices peut être comparée à des dalles de pavage sur des trottoirs. Au fur et à mesure que votre projet grandit, plus de tuiles sont ajoutées à votre passerelle. Si un composant est obsolète, il suffit de remplacer cette tuile par une nouvelle.
Cette architecture présente de nombreux avantages, mais je citerai les plus importants :
Premier exemple. La direction d'une plateforme de prêt P2P avec un grand nombre d'utilisateurs a décidé d'entrer sur les marchés de pays avec une devise différente. La plate-forme avait une architecture monolithique et ne comprenait qu'une seule devise - l'euro, et pour entrer sur les marchés de la Suède (couronne suédoise), de la Pologne (zloty polonais) et de la République tchèque (couronne tchèque), il était nécessaire d'introduire la multidevise.
Il a fallu des mois à toute l'équipe pour implémenter cette fonctionnalité, et le développement de nouvelles fonctionnalités a encore ralenti. Dans le cas d'une architecture microservice, tout serait beaucoup plus simple et rapide.
Deuxième exemple. Initialement, le constructeur de site a été lancé dans la langue maternelle et la direction n'allait pas s'étendre sur d'autres marchés. Le projet avait une architecture monolithique et la fonctionnalité s'est développée rapidement. Le schéma de la plate-forme était un réseau complexe dans lequel tout était connecté à tout. Un jour, l'entreprise a décidé de sortir une version de la plateforme dans d'autres langues. Au début, il semblait qu'il suffirait d'ajouter uniquement des fichiers de langue et maintenant nous aurons toute l'interface traduite.
En pratique, tout le projet a dû être refait. Par exemple, les noms d'entreprises et de produits dans la base de données doivent désormais être stockés non seulement dans une langue, mais dans chaque langue. Il était impossible de dupliquer les informations à cause de la logique métier, il fallait stocker les noms pour toutes les langues à la fois. En conséquence, cela a entraîné des changements dans les interfaces du espace client et du back office. Les changements d'interface ont nécessité de modifier les règles de validation des données entrantes, les modèles de lettres en raison de différents principes de terminaison dans différentes langues, la modification des tests, etc.
Comme tout était connecté à tout, la décision a été prise de passer à une architecture de microservices avec le lancement de nouveaux langages. Le processus de transition d'une architecture monolithique à une architecture de microservices a pris plus d'un an.
Troisième exemple. La plateforme fintech a été réalisée sur une ancienne version de PHP et Laravel. La mise à niveau vers des versions plus récentes, ainsi que le changement de la base de données de MariaDB vers PostgreSQL, étaient pratiquement impossibles, car toute l'équipe n'a dû gérer que le processus de migration pendant plusieurs mois.
Les nouvelles versions de PHP et de Laravel à cette époque pouvaient accélérer le projet et le développement ultérieur, mais l'architecture monolithique ne permettait pas de mettre à jour la pile technologique
.
