Kontaktujte nás pro personalizovanou nabídku FinMV přizpůsobenou vašim potřebám.
Technický ředitel vaší společnosti bude muset při plánování spuštění finanční platformy zvolit variantu architektury projektu. Jaké možnosti architektury má k dispozici a kterou je lepší zvolit?
Monolitická architektura je jako sněhová koule. Začnete projekt a máte malou sněhovou kouli. Je tak malý, že jej může vyvinout a převálcovat malý tým. Uplynulo pár let a nyní se vaše sněhová koule stala tak obrovskou, že ji již tlačí 20 vývojářů. Za několik dalších let budou stovky vývojářů válet vaši sněhovou kouli s tunou kódu, ale spouštění nových funkcí bude velmi pomalé.
V důsledku toho majitelé začnou měnit technického ředitele, členy týmu, ale je to jen horší. Noví členové týmu neznají historické detaily, proč je sněhová koule taková, jaká je, a ne jiná. Dokumentace k produktu rychle zastará.
Proč to neudělat hned od začátku? Za prvé, na úplném začátku podnikání jsou vždy omezené zdroje, není dostatek vývojářů, odborných znalostí a času. Manuál naléhá a programátoři spěchají, aby to udělali co nejrychlejším způsobem.
Zadruhé, techničtí inženýři si myslí: "Dobrá, ať je to zatím monolitická architektura, ale až firma poroste, pak všechno předěláme". Bohužel ve skutečnosti bude převod existujícího monolitického projektu na architekturu mikroslužeb desítkykrát obtížnější než napsat vše od začátku.
Vaši finanční platformu okamžitě vytvoříme na základě architektury mikroslužeb.
Architekturu mikroservisů lze přirovnat k dlažebním deskám na chodnících. Jak váš projekt roste, na váš chodník se přidávají další dlaždice. Pokud je komponenta zastaralá, stačí tuto dlaždici vyměnit za novou.
Tato architektura má mnoho výhod, ale uvedu ty nejdůležitější:
První příklad. Vedení platformy P2P půjček s velkým počtem uživatelů se rozhodlo vstoupit na trhy zemí s jinou měnou. Platforma měla monolitickou architekturu a zahrnovala pouze jednu měnu - euro, a pro vstup na trhy Švédska (švédská koruna), Polska (polský zlotý), České republiky (česká koruna) bylo nutné zavést multiměnu.
Celému týmu trvalo několik měsíců, než tuto funkcionalitu implementoval, a vývoj nové funkce se ještě více zpomalil. V případě architektury mikroslužeb by bylo vše mnohem jednodušší a rychlejší.
Druhý příklad. Zpočátku byl nástroj pro tvorbu stránek spuštěn v původním jazyce a vedení nehodlalo expandovat na další trhy. Projekt měl monolitickou architekturu a funkčnost rychle rostla. Schéma platformy bylo komplexní web, ve kterém bylo vše propojeno se vším. Jednoho dne se firma rozhodla vydat verzi platformy v jiných jazycích. Nejprve se zdálo, že bude stačit přidat pouze jazykové soubory a nyní si necháme přeložit celé rozhraní.
V praxi bylo nutné celý projekt předělat. Například názvy firem a produktů v databázi by nyní měly být uloženy nejen v jednom jazyce, ale v každém jazyce. Kvůli obchodní logice nebylo možné duplikovat informace, bylo nutné uložit názvy pro všechny jazyky najednou. To vedlo ke změnám v rozhraní kabinetu a back office. Změny rozhraní si vyžádaly změnu pravidel pro ověřování příchozích dat, šablon dopisů kvůli různým principům koncovek v různých jazycích, změny testů atd.
Vzhledem k tomu, že vše bylo propojeno se vším, padlo rozhodnutí přejít na architekturu mikroslužeb spolu se spuštěním nových jazyků. Proces přechodu z monolitické na mikroservisní architekturu trval více než rok.
Třetí příklad. Fintech platforma byla vytvořena na staré verzi PHP a Laravel. Upgrade na novější verze, stejně jako změna databáze z MariaDB na PostgreSQL, byly prakticky nemožné, protože celý tým se musel několik měsíců zabývat pouze procesem migrace.
Nové verze PHP a Laravel v té době mohly urychlit projekt a další vývoj, ale monolitická architektura neumožňovala aktualizaci technologického zásobníku
.
