Stručně: Přechod z monolitu na mikroslužby dává smysl teprve tehdy, když konkrétní limity společného nasazování, škálování nebo týmové koordinace pravidelně brzdí produkt. U menšího systému bývá bezpečnější nejprve zpřehlednit monolit, oddělit jeho moduly a až potom vyčleňovat samostatné služby.
- Stáří kódu samo o sobě není důvod k přepisu.
- Nejdříve pojmenujte měřitelný problém: pomalé nasazování, nestabilitu, náklady nebo blokované týmy.
- Mikroslužby přidávají síťovou, provozní a organizační složitost.
- Často dává největší smysl postupná modernizace místo kompletního přepisu.
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.
Která cesta odpovídá vaší situaci?
| Situace | Pravděpodobně vhodný krok | Co předem ověřit |
|---|---|---|
| Menší tým, rychlé změny a stabilní provoz | Ponechat monolit a zlepšit jeho modularitu | Hranice modulů, testy a proces nasazování |
| Jedna část systému výrazně zatěžuje zbytek | Oddělit konkrétní službu | Datové závislosti, monitoring a návratový plán |
| Více samostatných týmů a rozdílné nároky na škálování | Zvážit mikroslužby | Vlastnictví služeb, CI/CD, observabilitu a provozní kapacitu |
| Nejasné hranice domény a často měněné zadání | S přepisem počkat | Nejdříve stabilizovat produkt a pochopit doménu |
Co zjistit před rozhodnutím o přepisu
- Které konkrétní změny jsou dnes pomalé nebo rizikové?
- Je problém skutečně v architektuře, nebo v chybějících testech a procesu nasazování?
- Která část systému potřebuje škálovat nezávisle?
- Má tým kapacitu provozovat více služeb, jejich monitoring a komunikaci?
- Lze změnu provést postupně a zachovat fungující produkt?
Strategie „monolith first“ popisuje stejný princip: mikroslužby mají provozní cenu a jejich hranice se zpravidla navrhují lépe až ve chvíli, kdy tým rozumí skutečné doméně produktu. Podrobnější argumentaci nabízí Martin Fowler ve shrnutí Monolith First. Pokud řešíte modernizaci konkrétní aplikace, podívejte se také na projekty Reachways nebo nám popište současné omezení přes kontaktní formulář.
