Võtke meiega ühendust, et saada teie vajadustele kohandatud FinMV hinnapakkumine.
Teie ettevõtte tehniline direktor peab finantsplatvormi käivitamist kavandades valima projekti arhitektuuri valiku. Millised arhitektuurivõimalused on tal saadaval ja millist neist on parem valida?
Monoliitne arhitektuur on nagu lumepall. Alustate projekti ja teil on väike lumepall. See on nii väike, et seda saab arendada ja veeretada väike meeskond. Möödub paar aastat ja nüüd on teie lumepall muutunud nii suureks, et 20 arendajat juba pingutavad. Veel paari aasta pärast veeretavad sajad arendajad teie lumepalli tonni koodiga, kuid uute funktsioonide käivitamine muutub väga aeglaseks.
Selle tulemusena hakkavad omanikud vahetama tehnilist direktorit, meeskonnaliikmeid, kuid see läheb ainult hullemaks. Uued meeskonnaliikmed ei tea ajaloolisi üksikasju, miks lumepall on selline, mitte teine. Tootedokumentatsioon vananeb kiiresti.
Miks mitte teha seda kohe algusest peale? Esiteks on ettevõtte alguses alati ressursid on piiratud, pole piisavalt arendajaid, teadmisi ja aega. Kasutusjuhend on tungiv ja programmeerijatel on kiire, et seda teha võimalikult kiiresti.
Teiseks mõtlevad tehnikainsenerid: "Noh, olgu see praegu monoliitne arhitektuur, aga kui äri kasvab, siis teeme kõik uuesti". Kahjuks on tegelikkuses olemasoleva monoliitprojekti ülekandmine mikroteenuse arhitektuurile kümneid kordi keerulisem, kui kõike nullist kirjutada.
Teeme teie finantsplatvormi kohe mikroteenuse arhitektuurile tuginedes.
Mikroteenuste arhitektuuri võib võrrelda sillutisplaatidega jalgteedel. Projekti kasvades lisatakse teie kõnniteele rohkem plaate. Kui mõni komponent on vananenud, piisab selle plaadi asendamisest uuega.
Sellel arhitektuuril on palju eeliseid, kuid nimetan neist kõige olulisemad:
Esimene näide. Suure kasutajate arvuga P2P-laenuplatvormi juhtkond otsustas siseneda erineva valuutaga riikide turgudele. Platvormil oli monoliitne arhitektuur ja see sisaldas ainult ühte valuutat - eurot ning Rootsi (Rootsi kroon), Poola (Poola zlott), Tšehhi (Tšehhi kroon) turgudele sisenemiseks oli vaja kasutusele võtta multivaluuta.
Kogu meeskonnal kulus selle funktsionaalsuse juurutamiseks kuid ja uue funktsiooni arendamine aeglustus veelgi. Mikroteenuse arhitektuuri puhul oleks kõik palju lihtsam ja kiirem.
Teine näide. Algselt käivitati saidi koostaja emakeeles ja juhtkond ei kavatsenud teistele turgudele laieneda. Projektil oli monoliitne arhitektuur ja funktsionaalsus kasvas kiiresti. Platvormi skeem oli keeruline veeb, milles kõik oli kõigega seotud. Ühel päeval otsustas ettevõte välja anda platvormi versiooni teistes keeltes. Alguses tundus, et piisab ainult keelefailide lisamisest ja nüüd laseme tõlkida kogu liidese.
Praktikas tuli kogu projekt ümber teha. Näiteks ettevõtete ja toodete nimed andmebaasis tuleks nüüd salvestada mitte ainult ühes keeles, vaid igas keeles. Äriloogika tõttu ei olnud võimalik teavet dubleerida, oli vaja salvestada kõigi keelte nimed korraga. Sellest tulenevalt tõi see kaasa muudatusi kabineti ja tagakontori liidestes. Liidese muudatused nõudsid sissetulevate andmete valideerimise reeglite muutmist, tähemalle, mis tulenevad erinevatest keeltes lõpetamise põhimõtetest, testide muutmist jne.
Kuna kõik oli kõigega seotud, otsustati koos uute keelte turuletoomisega üle minna mikroteenuste arhitektuurile. Üleminek monoliitsest arhitektuurist mikroteenuste arhitektuurile võttis aega üle aasta.
Kolmas näide. Fintechi platvorm tehti PHP ja Laraveli vanal versioonil. Uuematele versioonidele uuendamine ja andmebaasi vahetamine MariaDB-st PostgreSQL-i oli praktiliselt võimatu, kuna kogu meeskond pidi mitu kuud tegelema ainult migratsiooniprotsessiga.
Tolleaegsed PHP ja Laraveli uued versioonid võisid projekti ja edasist arengut kiirendada, kuid monoliitne arhitektuur ei võimaldanud tehnoloogiapakki uuendada
.
