Kontaktirajte nas za personaliziranu ponudu FinMV-a prilagođenu vašim potrebama.
Tehnički direktor vaše tvrtke, prilikom planiranja pokretanja financijske platforme, morat će odabrati opciju arhitekture projekta. Koje su mu opcije arhitekture dostupne i koju je bolje odabrati?
Monolitna arhitektura je poput snježne grude. Pokrenete projekt i imate malu grudvu snijega. Toliko je malen da ga mali tim može razviti i razviti. Prošlo je nekoliko godina, a sada je vaša gruda snijega postala toliko ogromna da je 20 programera već forsira. Za još nekoliko godina, stotine programera će zakotrljati vašu grudvu snijega s tonom koda, ali pokretanje novih značajki postat će vrlo sporo.
Kao rezultat toga, vlasnici počinju mijenjati tehničkog direktora, članove tima, ali postaje samo gore. Novi članovi tima ne znaju povijesne detalje, zašto je gruda snijega takva kakva jest, a ne neka druga. Dokumentacija proizvoda brzo postaje zastarjela.
Zašto to ne učinite odmah od početka? Prvo, na samom početku poslovanja uvijek postoje resursi su ograničeni, nema dovoljno programera, stručnosti i vremena. Priručnik je nužan, a programeri se žure da to urade na najbrži mogući način.
Drugo, tehnički inženjeri misle: "Pa, neka za sada bude monolitna arhitektura, ali kad posao poraste, onda ćemo sve ponoviti". Nažalost, u stvarnosti će prenošenje postojećeg monolitnog projekta na mikroservisnu arhitekturu biti desetke puta teže od pisanja svega ispočetka.
Napravit ćemo vašu financijsku platformu odmah na temelju mikroservisne arhitekture.
Mikroservisna arhitektura može se usporediti s pločama za popločavanje na pješačkim stazama. Kako vaš projekt raste, na vašu se šetnicu dodaje više pločica. Ako je komponenta zastarjela, dovoljno je zamijeniti ovu pločicu novom.
Ova arhitektura ima mnoge prednosti, ali ću navesti najvažnije:
Prvi primjer. Uprava P2P platforme za kreditiranje s velikim brojem korisnika odlučila je ući na tržišta zemalja s drugom valutom. Platforma je imala monolitnu arhitekturu i uključivala je samo jednu valutu - euro, a za ulazak na tržišta Švedske (švedska kruna), Poljske (poljski zlot), Češke (češka kruna) bilo je potrebno uvesti multivalutu.
Trebali su mjeseci da cijeli tim implementira ovu funkcionalnost, a razvoj nove funkcionalnosti još se dodatno usporio. U slučaju mikroservisne arhitekture, sve bi bilo puno lakše i brže.
Drugi primjer. U početku je alat za izradu web stranica pokrenut na materinjem jeziku i menadžment se nije namjeravao širiti na druga tržišta. Projekt je imao monolitnu arhitekturu, a funkcionalnost je brzo rasla. Shema platforme bila je složena mreža u kojoj je sve bilo povezano sa svime. Jednog je dana tvrtka odlučila izdati verziju platforme na drugim jezicima. Isprva se činilo da je dovoljno dodati samo jezične datoteke, a sada ćemo imati prevedeno cijelo sučelje.
U praksi je cijeli projekt morao biti prerađen. Na primjer, nazivi tvrtki i proizvoda u bazi podataka sada bi trebali biti pohranjeni ne samo na jednom jeziku, već na svakom jeziku. Zbog poslovne logike bilo je nemoguće duplicirati informacije, bilo je potrebno pohraniti nazive za sve jezike odjednom. Sukladno tome, to je dovelo do promjena u sučeljima kabineta i pozadinskog ureda. Promjene sučelja zahtijevale su promjenu pravila za provjeru valjanosti dolaznih podataka, predložaka slova zbog različitih principa završetaka na različitim jezicima, promjene testova itd.
Budući da je sve bilo povezano sa svime, donesena je odluka o prelasku na mikroservisnu arhitekturu zajedno s lansiranjem novih jezika. Proces prijelaza s monolitne na mikroservisnu arhitekturu trajao je više od godinu dana.
Treći primjer. Fintech platforma je napravljena na staroj verziji PHP-a i Laravela. Nadogradnja na novije verzije, kao i promjena baze podataka iz MariaDB u PostgreSQL, bili su praktički nemogući, budući da se cijeli tim nekoliko mjeseci morao baviti samo procesom migracije.
Nove verzije PHP-a i Laravela u to vrijeme mogle su ubrzati projekt i daljnji razvoj, ali monolitna arhitektura nije dopuštala ažuriranje tehnološkog stoga
.
