Pišite nam za osebno ponudbo FinMV, prilagojeno vašim potrebam.
Tehnični direktor vašega podjetja bo moral pri načrtovanju zagona finančne platforme izbrati možnost arhitekture projekta. Kakšne arhitekturne možnosti so mu na voljo in katero je bolje izbrati?
Monolitna arhitektura je kot snežna kepa. Začnete projekt in imate majhno snežno kepo. Je tako majhen, da ga lahko razvija in razvija majhna ekipa. Minilo je nekaj let in zdaj je vaša snežna kepa postala tako velika, da jo 20 razvijalcev že spodbuja. Čez še nekaj let bo stotine razvijalcev zakotalilo vašo snežno kepo s tono kode, vendar bo uvedba novih funkcij postala zelo počasen.
Zaradi tega začnejo lastniki menjati tehničnega direktorja, člane ekipe, a se le še slabša. Novi člani ekipe ne poznajo zgodovinskih podrobnosti, zakaj je snežna kepa takšna, kot je in ne druga. Dokumentacija izdelka hitro zastari.
Zakaj tega ne storite takoj na začetku? Prvič, na samem začetku poslovanja so vedno viri omejeni, premalo razvijalcev, strokovnega znanja in časa. Priročnik nagovarja, programerji pa se mudi, da bi to naredili na najhitrejši možni način.
Drugič, tehnični inženirji mislijo: "No, naj bo to zaenkrat monolitna arhitektura, ko pa bo posel narastel, potem bomo vse popravili". Na žalost bo v resnici prenos obstoječega monolitnega projekta v arhitekturo mikrostoritev desetin krat težji kot pisanje vsega iz nič.
Vašo finančno platformo bomo takoj naredili na podlagi mikrostoritvene arhitekture.
Mikroservisno arhitekturo lahko primerjamo s tlakovnimi ploščami na pešpoteh. Ko vaš projekt raste, se na vašo pot doda več ploščic. Če je komponenta zastarela, je dovolj, da to ploščico zamenjate z novo.
Ta arhitektura ima številne prednosti, vendar bom navedel najpomembnejše:
Prvi primer. Vodstvo platforme za posojila P2P z velikim številom uporabnikov se je odločilo za vstop na trge držav z drugačno valuto. Platforma je imela monolitno arhitekturo in je vključevala samo eno valuto - evro, za vstop na trge Švedske (švedske krone), Poljske (poljski zlot), Češke (češke krone) pa je bilo treba uvesti večvaluto.
Potrebovali so mesece, da je celotna ekipa implementirala to funkcionalnost, razvoj nove funkcionalnosti pa se je še dodatno upočasnil. V primeru mikroservisne arhitekture bi bilo vse veliko lažje in hitreje.
Drugi primer. Sprva je bil graditelj spletnih mest predstavljen v maternem jeziku in vodstvo se ni nameravalo širiti na druge trge. Projekt je imel monolitno arhitekturo, funkcionalnost pa je hitro rasla. Shema platforme je bila zapleten splet, v katerem je bilo vse povezano z vsem. Nekega dne se je podjetje odločilo izdati različico platforme v drugih jezikih. Sprva se je zdelo, da bi bilo dovolj dodati samo jezikovne datoteke, zdaj pa bomo imeli preveden celoten vmesnik.
V praksi je bilo treba celoten projekt predelati. Na primer, imena podjetij in izdelkov v bazi podatkov bi morala biti zdaj shranjena ne samo v enem jeziku, ampak v vsakem jeziku. Zaradi poslovne logike je bilo nemogoče podvajati informacije, shraniti je bilo treba imena za vse jezike hkrati. Skladno s tem je prišlo do sprememb v vmesnikih kabineta in zaledne pisarne. Spremembe vmesnika so zahtevale spremembo pravil za preverjanje vhodnih podatkov, predlog črk zaradi različnih principov končnic v različnih jezikih, spreminjanje testov itd.
Ker je bilo vse povezano z vsem, je bila sprejeta odločitev za prehod na mikroservisno arhitekturo skupaj z uvedbo novih jezikov. Proces prehoda z monolitne na mikroservisno arhitekturo je trajal več kot eno leto.
Tretji primer. Platforma fintech je bila narejena na stari različici PHP in Laravel. Nadgradnja na novejše različice, pa tudi sprememba baze podatkov iz MariaDB v PostgreSQL je bila tako rekoč nemogoča, saj se je morala celotna ekipa več mesecev ukvarjati le s postopkom migracije.
Novi različici PHP in Laravel v tistem času bi lahko pospešili projekt in nadaljnji razvoj, vendar monolitna arhitektura ni omogočala posodabljanja tehnološkega sklada
.
