Contattaci per un preventivo FinMV personalizzato su misura per le tue esigenze.
Il direttore tecnico della tua azienda, quando pianifica il lancio di una piattaforma finanziaria, dovrà scegliere un'opzione di architettura del progetto. Quali opzioni di architettura sono a sua disposizione e quale è meglio scegliere?
Un'architettura monolitica è come una palla di neve. Inizi un progetto e hai una piccola palla di neve. È così piccolo che può essere sviluppato e lanciato da un piccolo team. Passano un paio d'anni e ora la tua valanga è diventata così grande che 20 sviluppatori la stanno già spingendo. Tra un paio d'anni, centinaia di sviluppatori lanceranno la tua valanga con un sacco di codice, ma il lancio di nuove funzionalità diventerà molto lento.
Di conseguenza, i proprietari iniziano a cambiare il direttore tecnico, i membri del team, ma la situazione peggiora solo. I nuovi membri del team non conoscono i dettagli storici, perché la palla di neve è così e non un altro. La documentazione del prodotto diventa rapidamente obsoleta.
Perché non farlo fin dall'inizio? In primo luogo, all'inizio di un'attività, ci sono sempre le risorse sono limitate, non ci sono abbastanza sviluppatori, esperienza e tempo. Il manuale è urgente e i programmatori hanno fretta di farlo nel modo più veloce possibile.
In secondo luogo, gli ingegneri tecnici pensano: "Beh, lascia che sia un'architettura monolitica per ora, ma quando l'azienda cresce, rifaremo tutto". Sfortunatamente, in realtà, trasferire un progetto monolitico esistente in un'architettura di microservizi sarà decine volte più difficile che scrivere tutto da zero.
Renderemo immediatamente la tua piattaforma finanziaria basata sull'architettura di microservizi.
L'architettura dei microservizi può essere paragonata alle piastrelle per pavimentazione sui marciapiedi. Man mano che il tuo progetto cresce, più tessere vengono aggiunte alla tua passerella. Se un componente è obsoleto, è sufficiente sostituire questo riquadro con uno nuovo.
Questa architettura ha molti vantaggi, ma nominerò i più importanti:
Primo esempio. La gestione di una piattaforma di prestito P2P con un numero elevato di utenti ha deciso di entrare nei mercati di paesi con una valuta diversa. La piattaforma aveva un'architettura monolitica e includeva una sola valuta - l'euro, e per entrare nei mercati di Svezia (corona svedese), Polonia (zloty polacco), Repubblica Ceca (corona ceca) era necessario introdurre la multivaluta.
Ci sono voluti mesi prima che l'intero team implementasse questa funzionalità e lo sviluppo di nuove funzionalità è ulteriormente rallentato. Nel caso di un'architettura di microservizi, tutto sarebbe molto più semplice e veloce.
Secondo esempio. Inizialmente, il costruttore del sito è stato lanciato nella lingua madre e la gestione non si sarebbe espansa in altri mercati. Il progetto aveva un'architettura monolitica e la funzionalità crebbe rapidamente. Lo schema della piattaforma era una rete complessa in cui tutto era connesso a tutto. Un giorno, l'azienda ha deciso di rilasciare una versione della piattaforma in altre lingue. All'inizio sembrava che bastasse aggiungere solo i file di lingua e ora avremo l'intera interfaccia tradotta.
In pratica, l'intero progetto doveva essere rifatto. Ad esempio, ora i nomi delle aziende e dei prodotti nel database dovrebbero essere archiviati non solo in una lingua, ma in ogni lingua. Era impossibile duplicare le informazioni a causa della logica aziendale, era necessario memorizzare i nomi di tutte le lingue contemporaneamente. Di conseguenza, ciò ha portato a cambiamenti nelle interfacce del gabinetto e del back office. Le modifiche all'interfaccia hanno richiesto la modifica delle regole per la convalida dei dati in entrata, i modelli di lettera a causa dei diversi principi di desinenza in lingue diverse, la modifica dei test, ecc.
Poiché tutto era connesso a tutto, è stata presa la decisione di passare a un'architettura di microservizi insieme al lancio di nuovi linguaggi. Il processo di transizione dall'architettura monolitica a quella a microservizi è durato più di un anno.
Terzo esempio. La piattaforma fintech è stata realizzata su una vecchia versione di PHP e Laravel. L'aggiornamento a versioni più recenti, così come la modifica del database da MariaDB a PostgreSQL, è stato praticamente impossibile, poiché l'intero team ha dovuto affrontare solo il processo di migrazione per diversi mesi.
Le nuove versioni di PHP e Laravel in quel momento potevano velocizzare il progetto e l'ulteriore sviluppo, ma l'architettura monolitica non permetteva l'aggiornamento dello stack tecnologico
.
