Mikroslužby vs.
Monolitická architektura

Dva přístupy k návrhu moderních systémů

Pokročilé programování

Bc. Pavel Bařina & Bc. Adam Novák
Univerzita Tomáše Bati

UTB

1 / 13

Co je softwarová architektura?

Rozdělení systému na komponenty a jejich vztahy
Conwayův zákon: struktura kódu kopíruje strukturu organizace
Kompromisy (trade-offs) — neexistuje univerzální řešení
Evoluce v čase — návrh musí vydržet roky, ne měsíce

2 / 13

Monolitická architektura

Jeden nasaditelný artefakt — celá aplikace v jednom balíčku
Všechny vrstvy v jednom procesu — UI, logika, data
Sdílená databáze pro všechny moduly
Historicky dominantní přístup: Rails, Django, Spring Boot, Laravel
Přirozený na začátku projektu

3 / 13

Výhody monolitu

Rychlý vývoj: veškerý kód na jednom místě, refactoring přes celý systém
Jednoduché nasazení: jedna CI/CD pipeline, jeden artefakt, triviální rollback
Snadné ladění: jeden stack trace, jeden log, debugger všude
Výkon in-process: nulová síťová latence, ACID transakce
Jednoduchá lokální vývoj: spustíte jednu aplikaci, bez Kubernetes či Docker

4 / 13

Nevýhody monolitu

„Big Ball of Mud": aplikace se postupně stane chaotickým spletecem (špatná orientace)
Problematické škálování: škáluje se celá aplikace, ačkoliv jen jedna funkce je přetížená
Technologický lock-in: všechny komponenty v jednom jazyce a frameworku
Pomalé release cykly: i malá změna znamená retest a nasazení celé aplikace
Těžký onboarding: vývojář musí chápat jednu velkou aplikaci

5 / 13

Mikroslužby

Rozdělená aplikace na malé, samostatné komponenty
Každá služba = má jasně zadanou jednu zodpovědnost
Vlastní databáze pro každou službu — bez sdílených tabulek
Nezávislé nasazení — změna v jedné službě ostatní neovlivní
Komunikace přes API / message broker — žádný přímý přístup k datům

6 / 13

Komunikace mezi mikroslužbami

Synchronní: čeká se na odpověď
REST — HTTP/JSON, snadné, ale pomalejší
gRPC — binární, HTTP/2, nízká latence
Asynchronní (Message Broker): fronty (RabbitMQ, Kafka)
Service Mesh (Istio, Linkerd): transparentní infrastruktura
Proxy, nahrazuje vlastní implementaci

7 / 13

Výhody mikroslužeb

Přesné škálování: škálujeme jen přetíženou službu, přímá úspora nákladů
Technologická flexibilita: ML v Pythonu, API v Go, frontend v Node.js
Izolace chyb: výpadek jedné služby nepadne celý systém
Autonomní týmy: každý tým vlastní celý lifecycle své služby
Nezávislé release cykly: každá služba se nasazuje nezávisle

8 / 13

Nevýhody mikroslužeb

Síťová latence: každé volání může selhat, timeout, špatná data
Složitá datová konzistence: bez ACID
Složité ladění: request přechází desítkami služeb, distribuované trasování nutné
Vysoké operační náklady: Kubernetes, service discovery, monitoring
Vyšší počáteční složitost: pro menší projekty často zbytečná (MVP)

9 / 13

Porovnání vlastností

Vlastnost	Monolith	Mikroslužby
Škálovatelnost	Nízká — škáluje se celek	Vysoká — škálují se části
Komplexita	Nízká — jednoduchá struktura	Vysoká — více služeb
Nasazení	Jedno — vše najednou	Oddělené — každá služba zvlášť
Snadnost startu	Snadný — jeden projekt	Složitější — více částí
Izolace chyb	Nízká — chyba ovlivní vše	Vysoká — chyba jen v jedné službě
Lokální vývoj	Jednoduchý	Náročnější — více služeb
Operační náklady	Nízké — méně infrastruktury	Vysoké — správa služeb

10 / 13

Reálné příklady z praxe

✦ Mikroslužby

movie

Netflix700+ mikroslužeb, 2M+ req/s

local_shipping

AmazonPrůkopníci mikroslužeb

directions_car

Uber2000+ mikroslužeb

✦ Monolit (úspěšně)

storefront

ShopifyRails monolit, $7B+ obratu

forum

Stack Overflow1B+ req/měsíc, ~9 serverů

cottage

BasecampRails monolit — filosofie

11 / 13

Kdy co použít?

view_in_ar

Monolit

Malý tým (2–8 vývojářů)
Nový / neověřený produkt
Jednoduchá doména
Rychlá iterace
Omezené DevOps kapacity
MVP — rychle na trh

hub

Mikroslužby

Více autonomních týmů
Skutečné škálovací požadavky
Jasné doménové hranice
Nezávislé release cykly nutné
Zralá DevOps kultura
Miliony requestů denně

12 / 13

Zdroje

[1] FOWLER, Martin a James LEWIS. Microservices [online]. 25. 3. 2014 [cit. 2026-03-30]. Dostupné z: https://martinfowler.com/articles/microservices.html
[2] RICHARDSON, Chris. Pattern: Microservice Architecture [online]. [cit. 2026-03-30]. Dostupné z: https://microservices.io/patterns/microservices.html
[3] AMAZON WEB SERVICES. Microservices on AWS [online]. 2023 [cit. 2026-03-30]. Dostupné z: https://aws.amazon.com/microservices/
[4] RED HAT. What are microservices? [online]. [cit. 2026-03-30]. Dostupné z: https://www.redhat.com/en/topics/microservices/what-are-microservices
[5] NEWMAN, Sam. Building Microservices: Designing Fine-Grained Systems. 2. vyd. Sebastopol: O'Reilly Media, 2021. ISBN 978-1-492-03402-5.
[6] NETFLIX TECHNOLOGY BLOG. Completing the Netflix Cloud Migration [online]. 2016 [cit. 2026-03-30]. Dostupné z: https://netflixtechblog.com/completing-the-netflix-cloud-migration-783514838d21
[7] KLEPPMANN, Martin. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. Sebastopol: O'Reilly Media, 2017. ISBN 978-1-449-37332-0.

13 / 13

Mikroslužby vs.Monolitická architektura