Rozdělit monolit nebo jej stabilizovat? Kritéria rozhodování pro modulární modernizaci

Pondělní ráno, 9:10: Odbor hlásí „malou úpravu“ v objednávkovém procesu. IT se krátce podívá do textu ticketu, vypadá uskutečnitelně. O dvě hodiny později je nálada jiná. Build běží déle než plánováno, vedlejší úloha visí na stejném Release-Paket, a po nahlédnutí do databáze je jasné: tato změna zasahuje více tabulek a Trigger, než se čekalo. Nejpozději nyní se objevuje otázka, která mnoho týmů pravidelně zaměstnává: rozdělit monolit nebo jej stabilizovat?

Kdo na to reflexně odpoví „Microservices!“, často přehlédne jádro: nejde o architektonickou nálepku, ale o schopnost dodávek a provozní spolehlivost. Tento praktický průvodce provede pragmatickým posouzením, ukáže rozhodovací kritéria pro modulární modernizaci a popíše realizovatelné kroky. Dále přináší typické chyby a jasné body pro ukončení a eskalaci – aby se modernizace nestala trvalým projektem bez měřitelného efektu.

Rozdělit monolit nebo stabilizovat: nejprve symptom, pak architektura

„Der Monolith ist schuld“ zní jednoznačně, ale zřídka je dostatečně přesné pro rozhodnutí. Monolit (aplikace jako společný Deployment-Artefakt) může běžet velmi spolehlivě – nebo trvale způsobovat problémy. Totéž platí opačně: Microservices (mnoho malých, samostatně deployovatelných služeb) mohou snížit průběžné časy, ale nevyhnutelně přinášejí více provozních úkolů.

Martin Fowler hodnotí tuto realitu střízlivě: Microservices jsou především jiný operační footprint – tedy jiná provozní náročnost s více komponentami, více nasazeními, více zdroji chyb a větší potřebou automatizace.^[Zdroj] Hranice tohoto tvrzení: nenahrazuje analýzu vašeho systému. Praktický závěr je přesto jasný: kdo si vyhlásí „Microservices“ jako cíl dříve, než je úzké hrdlo přesně popsáno, modernizuje rychle na špatném místě.

Kritéria rozhodování: Kdy rozdělení skutečně pomůže – a kdy ne

Tlaky na modernizaci jsou reálné: požadavky na bezpečnost rostou, rozhraní přibývají, týmy se mění a podniková aplikace má zároveň běžet dál a vyvíjet se. Rozdělení může být smysluplný krok – ale pouze pokud adresuje skutečné úzké hrdlo a nezkrášluje jen diagram architektury.

Kriterium 1: Provozní zralost – unese váš provoz tento footprint?

S každou další nasaditelnou jednotkou roste potřeba spolehlivého dodání a sledování: CI/CD (automatizovaný build/test/deploy řetězec), observability (metriky, logy a trace k diagnostice), procesy pro incidenty, runbooky a jasné odpovědnosti. AWS to formulují jako vážení: jemnější segmentace může přinést výhody v oblasti dostupnosti a škálování, zároveň ale zvyšuje provozní složitost s rostoucím počtem komponent.^[Zdroj] Hranice: jde o vodítko, nikoli záruku úspěchu. Důsledek: pokud dnes už máte potíže stabilně provést nasazení, pak taková landschaft služeb tento problém násobí.

Konkrétní kontrolní body, které nelze odbýt:

• Schopnost vydávání verzí: Rollback/Backout je definován, okna údržby a komunikace jsou zavedeny.
• Monitoring & alarmování: alarmy jsou akčně orientované (ne „všechno červené“), zdroje chyb jsou lokalizovatelné.
• Řízení incidentů: existuje rytmus pro postmortemy a opatření, ne jen ad-hoc hasičské zásahy.
• Ownership: kdo rozhoduje o rozhraních, kdo priorizuje, kdo nese provoz a kvalitu?

Kriterium 2: Odpojení změn – blokují se vzájemně požadavky?

Rozdělení má smysl, pokud jsou nezávislé změny v monolitu pravidelně vzájemně závislé, přestože jsou věcně oddělené. Typický vzor: část portálu vyžaduje časté úpravy, zatímco účtovací modul se mění zřídka a vyžaduje vysokou pečlivost. Pokud se obě vždy dostávají do stejného releasovacího tahu, brzdí se navzájem.

Naopak je rozdělení často vlastním průšvihem, pokud téměř každá změna protíná mnoho oblastí (oprávnění, cenová logika, reportování, čištění dat). V tom případě vytváříte místo odpojení pouze síť rozhraní – a koordinace roste místo toho, aby klesla.

Kritérium 3: Datové propojení – je složitost v databázi?

Mnoho systémů je více propojeno daty než kódem: sdílené tabulky, triggery, transakční postupy a dávkové úlohy. Sam Newman ve svých vzorech dekompozice zdůrazňuje, že skutečnou výzvou často bývá strategie dat a integrace – a že Big-Bang-Vorhaben jsou při tom zvlášť rizikové.^[Quelle]

Praktické důsledky pro provoz: Pokud více komponent zapisuje do stejných tabulek bez pravidel, vznikají vedlejší efekty, které lze jen těžko čistě vrátit zpět. Modulární modernizace proto vyžaduje včasná rozhodnutí o vlastnictví dat, konzistenci a oddělení reportingu.

Kritérium 4: Stabilita a odborná hodnota – co je třeba zachovat?

Ve vyvinutých digitálních podnikových řešeních často najdete mnoho správně implementované doménové logiky: speciální případy, obchodní pravidla, výjimky v procesech, historicky vzniklé čištění dat. To není „Legacy-Müll“, ale často důvod, proč podnik vůbec funguje. Modernizace dává ekonomický smysl, pokud tuto hodnotu nerozprodá bez rozmyslu – a zároveň identifikuje části, které činí provoz a další vývoj nepřiměřeně nákladnými.

Výběr: Tři cílové modely, které fungují v podnicích

Mezi „všechno zůstane“ a „všechno bude microservices“ leží praktikovatelná cílová schémata, která modernizaci činí plánovatelnou. AWS Prescriptive Guidance výslovně doporučuje před dekompozicí ověřit, které části by vůbec měly být dekomponovány, a upřednostňovat inkrementální přístupy.^[Quelle]

Praktický návod: Od prověření k realizaci (s body Stop/Go)

1) Zviditelnit hranice systému – dostatečně malé, aby se daly využít

Nepotřebujete 80stránkovou systémovou dokumentaci, abyste mohli rozhodnout. Pomůže kompaktní mapa: hlavní procesy, kritická rozhraní (např. portály, EDI, exporty souborů, REST-APIs), dávkové úlohy a místa s vysokou náchylností k poruchám. Cíl: umět činit rozhodnutí, ne archivovat znalosti.

Osvědčila se perspektiva, která spojuje provoz a obchodní oblast: „Která procesní trasa je kritická pro byznys a na čem technicky závisí?“ Pak rychle vynikne, kde by byla extrakce riziková – a kde by skutečně mohla přinést úlevu.

2) Definujte výchozí metriky – jinak to zůstane otázkou víry

Modernizace bez výchozího stavu je jako optimalizace výkonu bez měření. Klíčové jsou metriky, které zachycují jak doručování, tak provoz: frekvence nasazení (Deployment-Frequenz), Lead Time (od požadavku po produkci), Change Failure Rate (poruchovost po změnách), MTTR (Mean Time to Recovery) a opakující se třídy incidentů. Metriky nemusí být akademicky dokonalé – ale musí se sbírat konzistentně, aby bylo možné rozhodnout Stop/Go.

3) Výběr kandidátů na rozčlenění – podle domény, ne podle technických vrstev

Častým úvodním omylem je řez podle vrstev („UI-Service“, „DB-Service“). To vytváří nové závislosti místo jejich redukce. Řez podle domény znamená: modul nese odpovědnost za obchodní oblast včetně pravidel a dat. To je pro týmy obvykle lépe uchopitelné než čistě technická hranice.

Pokud nedokážete pojmenovat obchodní hranice, není to důvod řezat rychleji – ale signál, nejprve v monolitu stabilizovat a modulárně upravit: vyjasnit pojmy, pochopit datové toky, identifikovat průřezové funkce.

4) Strangler místo Big Bang – kontrolované přesměrování, důsledné odpojení

Pokud záleží na dostupnosti a je nutné řídit rizika, je vzorec Strangler Fig robustní postup: funkce se postupně nahrazují vedle existujícího systému; provoz se kontrolovaně přesměrovává, dokud staré cesty nejsou odpojeny.^[Zdroj]

Důležitá je disciplína stojící za vzorcem: jasná routingová rozhodnutí, kompatibilita dat a rozhraní, monitoring obou cest – a skutečné „Done“, když je stará cesta odstraněna. Jinak vznikne paralelní provoz jako trvalý stav.

5) Včas pevně stanovit strategii pro data a reporting

V praxi se modernizace často rozhoduje podle dvou otázek: kdo „vlastní“ která data – a jak se reportuje? Pokud reporting přistupuje přímo k provozním tabulkám, brání to změnám. Pokud více komponent „sdílí“ data bez pravidel, vznikají nekonzistence.

Plánujte proto explicitně:

• Vlastnictví dat: který modul je vedoucí pro kterou entitu (zákazník, objednávka, faktura …)?
• Požadavky na konzistenci: kde je potřeba silná konzistence, kde stačí eventuální konzistence?
• Oddělení reportingu: jak budou analýzy zásobovány daty, aniž by došlo k ztuhnutí provozních modelů?

6) Bezpečnost und provoz definujte pro každý modul – nelepte je na poslední chvíli

S každou novou komponentou se zvyšuje plocha útoku: komunikace služba‑ke‑službě, tajné klíče, oprávnění, auditní stopy. Ujasněte si včas, jak spolu souvisí autentizace (např. centrálně přes SSO) a autorizace (rolově-/právně založená pro každou doménu). Pro každodenní provoz navíc platí: logy musí být diagnosticky užitečné, ale nesmí porušovat pravidla ochrany osobních údajů a archivace. Tyto body patří do Runbooks a provozní dokumentace – ne jen do architektonických slidů.

8‑krokový kontrolní seznam pro spolehlivé rozhodnutí Go/No‑Go

1. Pojmenujte úzké místo: co přesně má být lepší (doba nasazení, stabilita, škálovatelnost, paralelní vývoj)?
2. Změřte výchozí stav: které metriky zobrazují aktuální stav (Lead Time, Change Failure Rate, MTTR apod.)?
3. Prověřte provozuschopnost: CI/CD, monitoring, alertování, Runbooks, procesy pro incidenty, odpovědnost.
4. Načrtněte doménové rozhraní: kde jsou přirozené odborné hranice? Co jsou průřezová témata?
5. Navrhněte strategii dat: vlastnictví dat, konzistence, reporting, migrační cesty.
6. Zdokumentujte závislosti: úlohy, rozhraní, exporty souborů, uživatelské skupiny, oprávnění.
7. Naplánujte slice: malý, dodavatelný balík včetně rollbacku a monitorovacích cílů.
8. Ustanovte Stop/Go‑kriteria: které signály zastaví rozdělení nebo nařídí stabilizační krok?

Typické chybové vzorce – takto se projevují v provozu

Chyba 1: Více komponent, ale žádná odpovědnost

Když nikdo není end‑to‑end zodpovědný (priorizace, kvalita, provoz), promění se oddělení v koordinační problém. V případě incidentu to vede k dlouhým kolům, nejasným rozhodnutím a reflexu znovu „všechno nasadit společně“. Protiopatření: pro každý modul jasný okruh vlastníků, definovaná předání a Decision‑Log pro rozhraní a vlastnictví dat.

Chyba 2: Sdílená data bez pravidel

Tento anti‑pattern je známý: služby jsou oddělené, ale stále zapisují do stejných tabulek nebo používají přímé přístupy do databáze napříč doménami. To narušuje izolaci, ztěžuje audity a činí rollbacky nespolehlivými. Opatření: přístupy k datům přes definovaná rozhraní, jasná datová odpovědnost a – kde je to nutné – kontrolovaná synchronizace (např. události).

Chyba 3: Síťová latence a kaskády chyb jsou „zahrnuty“ do plánu, ale netestují se

To, co byl v monolitu volání v rámci procesu, se v distribuovaných architekturách stává síťovým voláním s timeouty, retry a potenciálními kaskádami. Bez čistě definovaných timeoutů, korelace (Request‑IDs) a realistických end‑to‑end testů je analýza chyb výrazně obtížnější. Protiopatření: jasná SLO (měřitelné cíle služby), definované timeouty, trace‑korelace a zátěžové testy podél kompletních procesních tras.

Chyba 4: Rozdělení podle organizačního schématu místo podle doménové logiky

Pokud služby primárně zobrazují hranice týmů, ale odborně běží napříč procesy, zůstává vazba – pouze na jiné úrovni. Protiopatření: doménově ostré rozdělení, i když to zpočátku vyvolá tření. Pokud to organizačně není možné, je modulární monolit často lepším mezikrokem.

Přestávky a eskalační body: Kdy se stabilizace stává lepším rozhodnutím

Projekt modernizace potřebuje pravidla pro zastavení, jinak spotřebuje rozpočet a pozornost. Tyto signály jsou silné důvody k vědomému přepnutí:

• Provozní přetížení: příval alarmů, rostoucí MTTR, on-call už nelze pokrýt.
• Žádné měřitelné zlepšení: Lead Time, Change Failure Rate nebo stabilita se zjevně nezlepšují.
• Komplexita rozhraní exploduje: versionování nevyřešené, Breaking Changes se hromadí, ladění se stává hádankou.
• Datové konflikty: inkonzistence, duplikované pravdy, těžko vysvětlitelné odchylky v reportech.
• Vlastnictví zůstává nejasné: rozhodnutí trvají, nikdo nenese odpovědnost za provoz a další rozvoj.

Eskalace pak neznamená „zpět k starému“, ale: upřednostnit stabilizaci. Typická opatření jsou: dohnat regresi pro klíčové procesy, zlepšit Observability, konsolidovat přístupy k datům, zpřesnit hranice modulů v monolitu – a teprve poté znovu posoudit, zda má extrakce skutečný přínos.

Co konkrétně znamená „stabilizovat“ – a proč to často funguje rychleji

Stabilizace není kosmetická úklidová akce. V provozu se projeví méně překvapení a plánovatelná nasazení. Konkrétní páky, které týmy okamžitě pocítí:

• Mechanika releasů: reprodukovatelný build, konzistentní prostředí, osvědčená cesta pro rollback.
• Transparentnost: standardy logování, klasifikace chyb, korelace requestů napříč procesními trasami.
• Fokus na testy: end-to-end regresní testy pro klíčové toky (ne jen izolované testy).
• Hranice modulů v monolitu: definované interní APIs, disciplinovaný přístup k datům, jasné odpovědnosti.
• Hygiena dat: jednoznačné zdroje hlavních dat, zdokumentované vedlejší efekty jobů, redukovaná logika zvláštních případů.

Výsledkem je často robustní modulární monolit: software zůstává jako provozovatelná jednotka, ale interně je jasněji rozčleněný. Týmy tím získají mnoho z toho, co od rozdělení očekávají – bez okamžitého znásobení provozní složitosti.

Poslední kontrolní otázka, než se rozhodnete

Pokud byste dnes rozdělili: Dokážete zítra ráno při incidentu rychle říct, která část je odpovědná, kdo zasahuje, která metrika poruchu prokazuje a jak provedete rollback? Pokud tato otázka zůstává nepříjemně otevřená, není obvykle rozhodnutí „více architektury“, ale „více provozní bezpečnosti“.

Pokud chcete svou výchozí situaci strukturovaně zhodnotit a nastavit cestu modernizace s jasnými Stop/Go body, můžete nás za tímto účelem jednorázově a cíleně oslovit:

Pro toto téma jsou také důležité modernizace legacy systémů a vzor Strangler Fig. Příspěvek tyto aspekty srozumitelně zařazuje a ukazuje, na co záleží v praxi.

Projednat projekt nebo modernizační záměr s Net-Base.