Sazinieties ar mums, lai saņemtu personalizētu FinMV piedāvājumu, kas pielāgots jūsu vajadzībām.
Jūsu uzņēmuma tehniskajam direktoram, plānojot finanšu platformas palaišanu, būs jāizvēlas projekta arhitektūras variants. Kādas arhitektūras iespējas viņam ir pieejamas un kuru labāk izvēlēties?
Monlīta arhitektūra ir kā sniega bumba. Jūs sākat projektu, un jums ir maza sniega pika. Tas ir tik mazs, ka to var izstrādāt un ripināt neliela komanda. Paiet pāris gadi, un tagad jūsu sniega pika ir kļuvusi tik milzīga, ka jau 20 izstrādātāji to spiež. Vēl pēc pāris gadiem simtiem izstrādātāju ripinās jūsu sniega piku ar ļoti daudz koda, taču jaunu funkciju palaišana kļūs ļoti lēna.
Tā rezultātā īpašnieki sāk mainīt tehnisko direktoru, komandas biedrus, bet tas tikai pasliktinās. Jaunie komandas dalībnieki nezina vēsturiskās detaļas, kāpēc sniega pika ir tāda, kāda ir, nevis cita. Produkta dokumentācija ātri noveco.
Kāpēc to nedarīt jau no paša sākuma? Pirmkārt, pašā uzņēmējdarbības sākumā vienmēr ir resursi ir ierobežoti, nepietiek izstrādātāju, zināšanu un laika. Rokasgrāmata mudina, un programmētāji steidzas to izdarīt pēc iespējas ātrāk.
Otrkārt, tehniskie inženieri domā: "Pagaidām lai tā ir monolīta arhitektūra, bet, kad bizness augs, tad visu pārtaisīsim". Diemžēl patiesībā esoša monolīta projekta pārnešana uz mikropakalpojumu arhitektūru būs desmitiem reižu grūtāka nekā visu uzrakstīt no jauna.
Mēs nekavējoties izveidosim jūsu finanšu platformu, pamatojoties uz mikropakalpojumu arhitektūru.
Mikropakalpojumu arhitektūru var salīdzināt ar bruģa plāksnēm uz gājēju celiņiem. Projektam augot, jūsu celiņam tiek pievienots vairāk flīžu. Ja komponents ir novecojis, pietiek ar šīs flīzes nomaiņu ar jaunu.
Šai arhitektūrai ir daudz priekšrocību, taču es nosaukšu svarīgākās:
Pirmais piemērs. P2P aizdevumu platformas vadība ar lielu lietotāju skaitu nolēma ienākt to valstu tirgos, kurās ir atšķirīga valūta. Platformai bija monolīta arhitektūra un tajā bija tikai viena valūta – eiro, un, lai iekļūtu Zviedrijas (Zviedrijas kronas), Polijas (Polijas zloti), Čehijas (Čehijas krona) tirgos, bija nepieciešams ieviest multivalūtu.
Pagāja mēneši, līdz visa komanda ieviesa šo funkcionalitāti, un jaunas funkcionalitātes izstrāde palēninājās vēl vairāk. Mikropakalpojumu arhitektūras gadījumā viss būtu daudz vienkāršāk un ātrāk.
Otrais piemērs. Sākotnēji vietņu veidotājs tika palaists dzimtajā valodā, un vadība negrasījās paplašināties citos tirgos. Projektam bija monolīta arhitektūra, un funkcionalitāte strauji pieauga. Platformas shēma bija sarežģīts tīmeklis, kurā viss bija saistīts ar visu. Kādu dienu uzņēmums nolēma izlaist platformas versiju citās valodās. Sākumā likās, ka pietiks pievienot tikai valodu failus, un tagad liksim iztulkot visu interfeisu.
Praksē viss projekts bija jāpārstrādā. Piemēram, uzņēmumu un produktu nosaukumi datu bāzē tagad jāglabā ne tikai vienā valodā, bet katrā valodā. Biznesa loģikas dēļ informāciju nebija iespējams dublēt, bija jāsaglabā visu valodu nosaukumi vienlaikus. Attiecīgi tas izraisīja izmaiņas kabineta un aizmugures biroja saskarnēs. Mainot saskarni, bija jāmaina ienākošo datu validācijas noteikumi, burtu veidnes dažādu valodu galotņu atšķirīgo principu dēļ, jāmaina testi utt.
Tā kā viss bija saistīts ar visu, tika pieņemts lēmums pāriet uz mikropakalpojumu arhitektūru, ieviešot jaunas valodas. Pārejas process no monolītās uz mikropakalpojumu arhitektūru ilga vairāk nekā gadu.
Trešais piemērs. Fintech platforma tika izveidota uz vecās PHP un Laravel versijas. Jaunināšana uz jaunākām versijām, kā arī datu bāzes maiņa no MariaDB uz PostgreSQL bija praktiski neiespējama, jo visai komandai vairākus mēnešus bija jānodarbojas tikai ar migrācijas procesu.
Jaunās PHP un Laravel versijas tajā laikā varēja paātrināt projektu un tālāku attīstību, taču monolītā arhitektūra neļāva atjaunināt tehnoloģiju steku
.
