Kontaktujte nás pre personalizovanú ponuku FinMV prispôsobenú vašim potrebám.
Technický riaditeľ vašej spoločnosti si pri plánovaní spustenia finančnej platformy bude musieť vybrať architektúru projektu. Aké možnosti architektúry má k dispozícii a ktorú z nich je lepšie zvoliť?
Monolitická architektúra je ako snehová guľa. Začnete projekt a máte malú snehovú guľu. Je taký malý, že ho dokáže vyvinúť a zrolovať malý tím. Prešlo pár rokov a teraz sa vaša snehová guľa stala taká obrovská, že ju už tlačí 20 vývojárov. O niekoľko rokov budú stovky vývojárov valcovať vašu snehovú guľu s množstvom kódu, no spustenie nových funkcií bude veľmi pomalé.
V dôsledku toho majitelia začnú meniť technického riaditeľa, členov tímu, ale je to len horšie. Noví členovia tímu nepoznajú historické detaily, prečo je snehová guľa taká, aká je a nie iná. Dokumentácia k produktu rýchlo zastará.
Prečo to neurobiť hneď od začiatku? Po prvé, na úplnom začiatku podnikania sú vždy obmedzené zdroje, nedostatok vývojárov, odborných znalostí a času. Príručka nalieha a programátori sa ponáhľajú, aby to urobili čo najrýchlejším spôsobom.
Po druhé, technickí inžinieri si myslia: "Nuž, nech je to zatiaľ monolitická architektúra, ale keď podnik porastie, potom všetko prerobíme". Žiaľ, v skutočnosti bude prenos existujúceho monolitického projektu na architektúru mikroslužieb desaťdesiatkrátkrát náročnejší ako písanie všetkého od začiatku.
Vašu finančnú platformu okamžite vytvoríme na základe architektúry mikroslužieb.
Architektúru mikroservisov možno prirovnať k dlažbám na chodníkoch. Ako váš projekt rastie, na váš chodník sa pridávajú ďalšie dlaždice. Ak je komponent zastaraný, stačí túto dlaždicu vymeniť za novú.
Táto architektúra má veľa výhod, no vymenujem tie najdôležitejšie:
Prvý príklad. Vedenie P2P pôžičkovej platformy s veľkým počtom používateľov sa rozhodlo vstúpiť na trhy krajín s inou menou. Platforma mala monolitickú architektúru a obsahovala iba jednu menu - euro a pre vstup na trhy Švédska (švédska koruna), Poľska (poľský zlotý), Českej republiky (česká koruna) bolo potrebné zaviesť multimenu.
Trvalo mesiace, kým celý tím implementoval túto funkcionalitu a vývoj novej funkcionality sa ešte viac spomalil. V prípade architektúry mikroslužieb by bolo všetko oveľa jednoduchšie a rýchlejšie.
Druhý príklad. Pôvodne bol nástroj na tvorbu stránok spustený v rodnom jazyku a manažment sa nechystal expandovať na iné trhy. Projekt mal monolitickú architektúru a funkčnosť rýchlo rástla. Schéma platformy bola komplexná pavučina, v ktorej bolo všetko prepojené so všetkým. Jedného dňa sa firma rozhodla vydať verziu platformy v iných jazykoch. Najprv sa zdalo, že bude stačiť pridať iba jazykové súbory a teraz budeme mať preložené celé rozhranie.
V praxi sa musel celý projekt prerobiť. Napríklad názvy spoločností a produktov v databáze by teraz mali byť uložené nielen v jednom jazyku, ale v každom jazyku. Z dôvodu obchodnej logiky nebolo možné duplikovať informácie, bolo potrebné uložiť názvy pre všetky jazyky naraz. V súlade s tým to viedlo k zmenám v rozhraniach kabinetu a back office. Zmeny rozhrania si vyžiadali zmenu pravidiel pre overovanie prichádzajúcich údajov, šablóny listov z dôvodu odlišných princípov koncoviek v rôznych jazykoch, zmeny testov atď.
Keďže všetko bolo so všetkým prepojené, spolu so spustením nových jazykov padlo rozhodnutie prejsť na architektúru mikroslužieb. Proces prechodu z monolitickej na mikroservisnú architektúru trval viac ako rok.
Tretí príklad. Fintech platforma bola vytvorená na starej verzii PHP a Laravel. Upgrade na novšie verzie, ako aj zmena databázy z MariaDB na PostgreSQL boli prakticky nemožné, keďže celý tím sa musel niekoľko mesiacov zaoberať iba procesom migrácie.
Nové verzie PHP a Laravel v tom čase mohli urýchliť projekt a ďalší vývoj, ale monolitická architektúra neumožňovala aktualizáciu technologického zásobníka
.
