Monolit není sprosté slovo
Monolitická architektura má v technologickém světě trochu neprávem špatnou pověst. Jakmile aplikace začne růst, často se objeví první návrhy na kompletní přepis do mikroslužeb. Jenže změna architektury sama o sobě problém neřeší.
Dobře navržený monolit může být rychlý, stabilní a velmi efektivní. Pro menší a středně velké produkty bývá často dokonce praktičtější než složitá síť samostatných služeb.
Problém přichází ve chvíli, kdy architektura začne brzdit samotný byznys.
Jak poznat, že současné řešení přestává stačit?
Typický signál není jen „máme starý kód“.
Horší je situace, kdy každá změna vyžaduje zásah do několika vzájemně provázaných částí systému. Deploy nové funkce začne být rizikový, vývojáři se bojí upravovat starší části aplikace a jednoduchý požadavek se místo jednoho dne realizuje týden.
Postupně roste technický dluh a s ním i cena každé další změny.
V tu chvíli už není hlavní otázkou, zda je kód elegantní. Důležitější je, kolik firmu současná architektura stojí v čase, penězích a ztracených příležitostech.
Mikroslužby nejsou automatická odpověď
Rozdělení systému na menší služby přináší řadu výhod. Jednotlivé části lze nasazovat samostatně, lépe škálovat a rozdělit mezi více týmů.
Současně ale vzniká úplně nová vrstva složitosti.
Najednou řešíte komunikaci mezi službami, monitoring, autentizaci, síťové chyby, verzování API nebo distribuované transakce. Co bylo v monolitu obyčejným voláním funkce, může být nově komunikace mezi několika systémy.
Proto nedává smysl přecházet na mikroslužby jen proto, že jsou modernější.
Často funguje postupná modernizace
Kompletní přepis systému od nuly bývá jedna z nejrizikovějších variant.
Starý systém totiž často obsahuje roky drobných business pravidel, výjimek a procesů, které nikde nejsou zdokumentované. Při kompletním přepisu je velmi snadné část z nich ztratit.
Mnohem bezpečnější bývá systém rozdělovat postupně.
Nejproblematičtější nebo nejvíce zatěžované části lze oddělit jako první a zbytek aplikace ponechat funkční. Nová architektura tak vzniká vedle stávajícího systému, aniž by firma musela na několik měsíců zastavit vývoj produktu.
Technologie musí následovat byznys
Architektura není cíl. Je to nástroj.
Pokud současný systém zvládá provoz, změny se nasazují rychle a vývojový tým v něm dokáže efektivně pracovat, není důvod ho přepisovat jen kvůli technologickému trendu.
Pokud ale technické limity začínají brzdit růst firmy, potom je čas přemýšlet nad změnou.
Nejdřív je potřeba pochopit problém. Teprve potom vybírat technologii.
