Vím, že se to technologickým puristům asi nebude líbit, ale mé zkušenosti s mikroslužbami jsou odrazující. V praxi ten návrh vede ke křehkému, obtížně udržovatelnému a hlavně netestovatelnému systému, byť to na první pohled vypadá jinak. Jestli chce zákazník funkční výsledek v rozumné době, pak je pro mne dnes, po několika projektech různého typu, monolitické řešení první volbou.
Někdo o mikroslužbách psal: „Pokud neumíte správně navrhnout architekturu monolitu, proč si myslíte, že s mikroslužbami dopadnete lépe?“ Nemyslím si, že by to byl problém primárně zvolené koncepce (monolit × mikroslužby). Podle mne monolit snese horší architekturu, mikroslužby umožňují lepší škálování, ale daní za to je, že musí být lépe navržená architektura a lépe řešit chybové stavy. Pokud tedy někdo nechce investovat do architektury, automatizovaného testování a správy, je pro něj lepší použít monolit.
Rozumím a souhlasím, není to problém koncepce. Mluvím o rozdílu mezi teorií a reálnou praxí ve skutečném prostředí. V realitě tlak na termíny a cenu a nedostatek kvalifikovaných odborníků vedou k upřednostnění centralizovaných all-in-one řešení. Jsou srozumitelnější a přímočařejší.
Obvyklý životní cyklus systému začíná MVP, na němž se vyzkouší tržní úspěšnost. Pokud uspěje, pokračuje se rozvíjením existujícího, ne kompletní přestavbou - do toho žádný investor nedá peníze. Škálovatelnost vyjma opravdu velkých systémů v těchto fázích nikoho nezajímá, dostupný hardware výkonově postačuje, nebo se škáluje databáze, kde to drhne nejvíc. A po pár letech, až se problémy nakupí, je tu něco tak velkého, že se to za přijatelný čas a peníze prostě nedá přepsat.
Mluvím o rozdílu mezi teorií a reálnou praxí ve skutečném prostředí. V realitě tlak na termíny a cenu a nedostatek kvalifikovaných odborníků vedou k upřednostnění centralizovaných all-in-one řešení. Jsou srozumitelnější a přímočařejší.
Ne, tlak na termíny a na cenu vede k tomu, že výsledek je horší. A to je to, co jsem psal – že monolit snese horší řešení.