Monolit, modulární monolit, nebo microservices? Jak zvolit architekturu aplikace

Microservices patří k nejčastěji skloňovaným pojmům v softwarové architektuře. Slibují rychlejší vývoj, snadné škálování a nezávislé týmy. Nejsou ale jedinou možností a za své výhody se platí složitostí, kterou na první pohled nevidíte. Srovnáváme tři hlavní přístupy, monolit, modulární monolit a microservices, a ukazujeme, podle čeho mezi nimi vybrat.

Tři přístupy k architektuře aplikace

Architekturu aplikace lze zjednodušeně postavit třemi způsoby: jako monolit, modulární monolit, nebo microservices. Liší se tím, jestli aplikace běží jako jeden celek, nebo jako soubor samostatných služeb, a jak pevné hranice mají její jednotlivé části.

• Monolit: celá aplikace se vyvíjí, testuje a nasazuje jako jeden celek. Všechny části sdílejí kód i databázi.
• Modulární monolit: aplikace se pořád nasazuje jako jeden celek, ale uvnitř je rozdělená na moduly podle byznysových oblastí (objednávky, zákazníci, fakturace) s jasně definovanými hranicemi.
• Microservices: aplikace se skládá z mnoha malých, samostatně běžících služeb. Každá služba řeší jednu oblast (třeba objednávky, platby nebo uživatelské účty), má vlastní data a s ostatními komunikuje přes API.

Rozdíl si můžete představit na firmě, která roste. Dokud sedí celý tým v jedné kanceláři, většinu věcí vyřešíte otočením na židli. Rozhodnutí jsou rychlá, všichni vidí všechno, ale s růstem začne být těsno a nikdo už přesně neví, kdo za co odpovídá. Další krok je budova s odděleními: každé má svou agendu a jasná pravidla spolupráce, ale pořád jste pod jednou střechou. Když firma otevře pobočky v dalších městech, každá může fungovat samostatně, vlastním tempem a s vlastním vedením. Zároveň ale musíte zavést pravidla, kdo za co odpovídá, jak si pobočky předávají informace a co se stane, když jedna z nich přestane odpovídat.

Přesně tak se liší tři přístupy k architektuře. Monolit je jedna kancelář, modulární monolit budova s odděleními, microservices síť poboček. S každým krokem roste samostatnost jednotlivých částí, ale i režie na jejich koordinaci.

Obecný úvod do toho, jak se architektura navrhuje a jaké styly existují, najdete v článku Softwarová architektura: definice, komponenty, benefity.

Proč se o volbě architektury znovu diskutuje

Microservices se na několik let staly synonymem moderní architektury, ale od roku 2023 je debata vyváženější. Část firem, které je zavedly, veřejně popsala, proč se u některých systémů vrátila k jednoduššímu uspořádání.

Microservices proslavily technologické firmy, které potřebovaly, aby stovky vývojářů mohly pracovat nezávisle. Z jejich řešení organizačního problému se ale postupně stal obecný trend. Pak přišly příklady opačným směrem:

• Amazon Prime Video přestavěl nástroj pro kontrolu kvality videostreamů z distribuovaného řešení do jedné aplikace a snížil náklady na infrastrukturu o více než 90 %. Šlo o jednu konkrétní službu, ne o celý Prime Video, a velkou část úspory tvořil cenový model použitých cloudových služeb.
• Segment v roce 2018 sloučil stovky služeb své hlavní datové platformy zpět do jedné. Před sloučením se při takovém počtu služeb objevoval výpadek zhruba každý den a půl.
• Shopify microservices pro své jádro vědomě odmítl a zvolil modulární monolit. Kód rozdělili podle byznysových oblastí s jasnými hranicemi, ale nasazují ho jako jeden celek.

Nejde o to, že by microservices nefungovaly. Tyto příběhy ukazují, že jde o nástroj pro konkrétní typ problému. Martin Fowler, jeden z nejcitovanějších autorů o softwarové architektuře, to shrnul už v roce 2015 v článku Monolith First: téměř všechny úspěšné příběhy microservices začaly monolitem, který přerostl a byl rozdělen.

Monolit: jednoduchost, která má své limity

Monolit je nejjednodušší způsob, jak aplikaci postavit i provozovat, ale bez vnitřní struktury se s růstem stává těžkopádným.

Co monolit přináší:

• Rychlý start. Jeden projekt, jedna databáze, jedno nasazení. Tým se může soustředit na funkce, ne na infrastrukturu.
• Jednoduchý provoz. Stačí méně serverů, méně nástrojů a méně specializovaných lidí.
• Snadné testování a hledání chyb. Celou aplikaci spustíte najednou a chybu dohledáte na jednom místě.
• Konzistence dat. Objednávka i odečet skladu proběhnou v jedné databázové transakci.

Kde narazí:

• Prorůstání kódu. Bez jasných hranic se části aplikace postupně začnou navzájem volat napříč a změna v jednom místě může nečekaně rozbít jiné.
• Škálování celku. Když zátěž roste jen v jedné části, musíte posílit celou aplikaci.
• Více týmů v jednom kódu. Jakmile na monolitu pracuje víc týmů, začnou na sebe čekat a řešit konflikty.
• Každá změna znamená nasazení celé aplikace. I drobná úprava jde do produkce spolu se vším ostatním.

Modulární monolit: jednoduchý provoz s jasnými hranicemi

Modulární monolit kombinuje jednoduchost jednoho nasazení s disciplínou jasných hranic uvnitř aplikace. Řeší hlavní slabinu klasického monolitu, prorůstání kódu, a přitom si nebere provozní režii microservices.

Aplikace je rozdělená na moduly podle byznysových oblastí (objednávky, zákazníci, fakturace). Každý modul má vlastní odpovědnost a s ostatními komunikuje přes definované rozhraní, ne přímým zásahem do jejich dat. Nasazuje se ale pořád jako jeden celek, takže odpadá většina provozní režie distribuovaného systému.

Tento přístup má dvě praktické výhody:

1. Získáte čas poznat svůj byznys. Na začátku projektu ještě nevíte, které části porostou, které se budou často měnit a kde vedou skutečné hranice. Moduly se dají přeskládat výrazně levněji než samostatné služby.
2. Necháváte si otevřené dveře. Dobře oddělený modul lze později vyčlenit do samostatné služby, až to bude dávat smysl. Přechod je pak evoluce, ne přestavba.

Má ale i své limity. Hranice mezi moduly musí někdo hlídat, jinak se modulární monolit časem změní v obyčejný. Aplikace se pořád škáluje a nasazuje jako celek, takže u velmi rozdílné zátěže jednotlivých částí nebo u mnoha týmů může narazit podobně jako klasický monolit.

Microservices: co přinášejí a co stojí

Hlavní přínos microservices je nezávislost: jednotlivé části systému lze vyvíjet, nasazovat a škálovat samostatně. Cenou za tuto nezávislost je výrazně složitější provoz a koordinace.

Co microservices přinášejí

U velkého systému s několika týmy může nezávislost služeb výrazně zrychlit vývoj:

• Nezávislé nasazování. Úprava např. v platbách nečeká na dokončení práce v katalogu. Každý tým vydává změny ve vlastním tempu.
• Škálování jen toho, co je potřeba. Pokud jedna část systému nese výrazně větší zátěž (třeba vyhledávání během výprodeje), posílíte jen ji, ne celou aplikaci.
• Izolace chyb. Při dobrém návrhu výpadek jedné služby neshodí celý systém. Uživatel třeba nevidí doporučené produkty, ale nakoupit může dál.
• Samostatnost týmů. Každý tým vlastní svou službu od kódu po provoz, což zjednodušuje odpovědnost i rozhodování.
• Technologická volnost. Každá služba může používat technologii, která se pro její úlohu hodí nejlépe. V praxi je ale rozumné tuto volnost omezovat, jinak roste náročnost údržby.

Kolik microservices stojí

Microservices přesouvají složitost z kódu do provozu a koordinace. Systém složený z desítek služeb je distribuovaný systém a ten má vlastní nároky, které u monolitu vůbec neřešíte:

• Infrastruktura a DevOps. Každá služba potřebuje vlastní nasazení, konfiguraci, zabezpečení a zdroje. Bez automatizace a nástrojů typu Kubernetes se to nedá rozumně zvládnout a i s nimi to vyžaduje zkušené lidi.
• Monitoring a hledání chyb. Když se něco pokazí, chyba může vzniknout v jedné službě a projevit se v úplně jiné. Bez centrálního logování a sledování požadavků napříč službami se hledání příčiny protahuje.
• Konzistence dat. U monolitu proběhne objednávka i odečet skladu v jedné transakci. U microservices musíte navrhnout, co se stane, když jedna služba změnu provede a druhá ne.
• Síťová komunikace. Volání mezi službami je pomalejší a méně spolehlivé než volání uvnitř jedné aplikace. Musíte počítat s výpadky, zpožděními a opakováním.
• Nároky na tým. Návrh hranic mezi službami, API a provoz distribuovaného systému vyžadují zkušenosti, které menší týmy často nemají.

Nejhorší výsledek je takzvaný distribuovaný monolit: systém rozdělený na služby, které jsou na sobě ve skutečnosti tak závislé, že se stejně musí vyvíjet a nasazovat společně. Platíte veškerou režii microservices a nezískáte téměř žádnou z jejich výhod. Nejčastěji vzniká, když se systém rozdělí dřív, než je jasné, kde vedou přirozené hranice mezi jeho částmi. Neuvážené architektonické rozhodnutí se pak dlouhodobě projevuje jako technický dluh.

Srovnání v přehledu

Žádný ze tří přístupů není univerzálně nejlepší: liší se tím, kolik jednoduchosti vyměníte za nezávislost jednotlivých částí. Tabulka shrnuje hlavní rozdíly.

Jak vybrat správnou architekturu

Při volbě architektury rozhoduje hlavně velikost systému a týmu, rozdílnost zátěže jednotlivých částí, jak dobře znáte hranice mezi nimi a jaké máte možnosti provozu. Podle toho se dá rozhodnout poměrně jednoznačně.

Kdy stačí monolit

• Aplikace je menší a nečekáte, že bude výrazně růst (interní nástroj, jednodušší portál).
• Na vývoji pracuje jeden menší tým.
• Potřebujete rychle ověřit nápad a počítáte s tím, že první verzi později přepracujete.

Kdy zvolit modulární monolit

Pro většinu nových produktů doporučujeme začít modulárním monolitem a microservices zvažovat až ve chvíli, kdy pro ně máte konkrétní důvod. Modulární monolit dává smysl, když:

• Stavíte produkt, který má dlouhodobě růst, ale hranice mezi jeho částmi se teprve ustalují.
• Na systému pracuje jeden až několik týmů.
• Chcete mít otevřenou cestu k pozdějšímu vyčlenění služeb, ale bez provozní režie od prvního dne.

Kdy přejít na microservices

Microservices se vyplatí tehdy, když jejich přínos (nezávislost týmů a částí systému) převáží náklady na složitější provoz. V praxi to poznáte podle kombinace těchto signálů:

1. Na systému pracuje několik týmů, které si navzájem překážejí. Čekají na sebe s nasazením, řeší konflikty v kódu a koordinace zabírá víc času než samotný vývoj.
2. Části systému mají výrazně odlišnou zátěž. Například veřejné vyhledávání zažívá velké špičky, zatímco administrace běží stabilně. Škálovat celou aplikaci kvůli jedné části je drahé.
3. Části systému potřebují jiné tempo změn nebo jiný režim. Platební modul s přísnými bezpečnostními a regulatorními požadavky se vyplatí oddělit od částí, které se mění každý týden.
4. Hranice mezi oblastmi jsou jasné a stabilní. Víte, co patří k objednávkám a co k fakturaci, a tyto hranice se roky nemění.
5. Máte tým a procesy na provoz distribuovaného systému. Automatizované nasazování, monitoring a zkušenost s DevOps jsou předpoklad, ne něco, co se dořeší za pochodu.

Naopak pokud stavíte MVP, máte jeden menší tým, hranice mezi částmi produktu se teprve hledají nebo je hlavním důvodem „chceme moderní architekturu“, microservices vám pravděpodobně přinesou víc nákladů než užitku.

Volba nemusí být definitivní ani černobílá

Častým a rozumným řešením je modulární monolit s jednou nebo dvěma samostatnými službami tam, kde je to opravdu potřeba, například pro náročné zpracování dat nebo napojení na externí systém. Architektura se navíc může vyvíjet postupně: z monolitu se zavedením hranic stane modulární monolit a z něj lze časem vyčlenit služby, které to potřebují.

Podobnou logiku popisujeme i u headless CMS: architektura má odpovídat problému, který skutečně řešíte, ne trendu.

Volba architektury a vývoj s pomocí AI

AI-assisted vývoj přidává k volbě architektury nový pohled: AI nástroje pracují tím lépe, čím přehlednější a lépe ověřitelný je kód, se kterým pracují. Architektura tak ovlivňuje i to, kolik vám AI ve vývoji skutečně přinese.

Podle zprávy DORA 2025 od Google Cloud funguje AI jako zesilovač: posiluje to, co už v týmu a systému je. Dobře strukturovaný systém s rychlými testy z ní vytěží víc, nepřehledný systém s ní může být nepřehledný rychleji. Odborníci zabývající se architekturou upozorňují, že AI nástroje si nejlépe vedou, když mají potřebný kontext na jednom místě a změny mohou hned ověřit testy. U změn, které se táhnou přes víc samostatných služeb, je to těžší.

Neznamená to, že AI a microservices nejdou dohromady. Platí ale stejné pravidlo jako bez AI: jasné hranice, dobré rozhraní a automatické testy. Modulární monolit tyto podmínky splňuje přirozeně, u microservices je musíte cíleně zajistit.

Jak o architektuře rozhodujeme v Argo22

Architekturu volíme až podle toho, co projekt skutečně potřebuje: jaké má byznysové cíle, jakou zátěž, kolik integrací a jaký tým ho bude dlouhodobě rozvíjet. Volba mezi monolitem, modulárním monolitem a microservices proto přichází na řadu až po analýze, ne na začátku nabídky.

Typické otázky, které si v úvodní fázi projektu klademe:

• Které části systému porostou nejrychleji a které budou nejvíc zatížené?
• Na jaké firemní systémy se musíme napojit a jak dobře jsou připravené?
• Kdo bude systém rozvíjet za tři roky: náš tým, váš interní tým, nebo obojí?
• Jaké jsou bezpečnostní a regulatorní požadavky na jednotlivé části?

Dobře to ilustruje platforma E.ON Propojeno pro sdílení elektřiny. Klíčovou součástí architektury bylo navržení integrační vrstvy, přes kterou se platforma napojuje na 9 systémů (mimo jiné SAP, EDC a DMS) s různou úrovní připravenosti API, včetně systémů bez standardního rozhraní. Platforma stojí na open-source technologiích v infrastruktuře E.ON, bez vendor lock-inu, a je navržená tak, aby zvládla postupné rozšiřování počtu uživatelů.

Stavíme na otevřených technologiích, aby vás žádné architektonické rozhodnutí nesvázalo s jedním dodavatelem. Systém, který dnes začíná jako modulární monolit, tak může později růst směrem, který bude dávat smysl vašemu byznysu.

Řešíte architekturu nového systému?

Monolit je rychlá cesta pro menší aplikace, microservices silný nástroj pro velké systémy s mnoha týmy. Pro většinu projektů je ale nejlepším startem modulární monolit s jasnými hranicemi, který se dá později rozdělit tam, kde to přinese skutečný užitek.

Pokud plánujete nový systém nebo řešíte, jestli ten stávající ještě unese další růst, podívejte se, jak přistupujeme k vývoji webových aplikací na míru. Nebo nám rovnou napište a společně projdeme, jaká architektura dává smysl právě vám.