Co jsou mikroservisy

Od monolitů k mikroservisům

Mikroservisy jsou architektonický styl, ve kterém je aplikace složena z malých, samostatně nasaditelných služeb komunikujících přes síť pomocí jasně definovaných rozhraní. Každá služba implementuje úzké, dobře ohraničené byznysové schopnosti a je nezávislá co do vývoje, nasazení, škálování i volby technologií. Tento přístup kontrastuje s monolitem, kde je logika systému, data i uživatelská rozhraní balena do jednoho spustitelného artefaktu a nasazována jako celek.

Proč monolity dlouho dominovaly a kde narážejí

• Jednodušší start: jediný repozitář, jednotné testy, „jeden build – jedno nasazení“.
• Silná konzistence v rámci jednoho procesu (transakce, sdílené objekty, společné knihovny).
• Limity růstu: těžkopádné releasy, pomalé buildy, vysoká míra vzájemných závislostí, obtížné škálování pouze části systému.
• Organizační překážky: mnoho týmů zasahuje do téže codebase; fronty na releasy, konflikty priorit, „big bang“ integrace.

Definice mikroservisů a klíčové vlastnosti

• Samostatné nasazení: každá služba je verzována, buildována a releaseována nezávisle.
• Byznysově orientované rozhraní: API popisuje doménové capability, nikoli tabulky či interní objekty.
• Data ownership: každá služba má své úložiště (polyglot persistence); žádné sdílené databázové schéma mezi službami.
• Izolace poruch: chyba v jedné službě nevyřadí celý systém.
• Nezávislé škálování: služby škálují podle vlastní zátěže, nikoli podle největšího společného jmenovatele.

Proč mikroservisy nahradily monolity (v mnoha případech)

• Rychlost změn: menší codebase na tým, kratší lead time, možnost deployovat několikrát denně.
• Organizační sladění: Conwayův zákon – týmy tvoří služby, které odrážejí jejich komunikační struktury; vlastnictví od nápadu po provoz (you build it, you run it).
• Technologická volnost: každá služba může zvolit nejlepší nástroj (jazyk, framework, databázi) pro daný problém.
• Odolnost a škálování: horizontální škálování jen tam, kde je třeba; graceful degradation při dílčích výpadcích.

Doménový návrh a hranice služeb

Základ kvality rozdělení tvoří Domain-Driven Design (DDD). Systém dělíme podle bounded contexts – relativně autonomních oblastí byznysu se samostatným modelem a jazykem.

• Heuristiky rozdělení: vysoká koheze uvnitř, nízké vazby ven; stabilní API na hranici; různé tempo změn.
• Antipattern: dělení podle vrstev (UI/Service/DB) vede k mini-monolitům a těsné vazbě.
• Kontrakty: explicitní API (REST/JSON, gRPC, GraphQL), schémata a verze (SemVer), consumer-driven contract testing.

Komunikace: synchronní vs. asynchronní

• Synchronní (HTTP/gRPC): jednoduchá integrace, přímé dotazy; riziko kaskádových timeoutů – nutné circuit breaker, timeouts, retries with backoff, bulkhead.
• Asynchronní (eventy, message broker): volné vazby, lepší odolnost a škálování; vyžaduje idempotenci, deduplikaci, outbox a exactly-once nelze očekávat bez kompromisů.
• Event-driven architektura: služby publikují doménové události (OrderPlaced), ostatní reagují; snižuje potřebu orchestrátorů.

Konzistence dat: od ACID k eventual consistency

V distribuovaném systému nelze spoléhat na transakce napříč službami. Místo toho:

• Sagy: choreografie (reakce na události) nebo orchestrace (centrální koordinátor) s kompenzačními kroky.
• Outbox pattern: atomické zapsání změny a události do lokální DB, následná spolehlivá publikace.
• Read modely: materializované pohledy pro rychlé čtení, CQRS pro oddělení zápisu a čtení.

API Gateway, BFF a edge

• API Gateway: jednotný vstup, autentizace/autorizace, rate limiting, routing, observabilita, transformace.
• Backend for Frontend (BFF): specializované API pro jednotlivé klienty (web/mobil) – snižuje chatty komunikaci a složitost v UI.
• GraphQL / agregace: vhodné pro složité dotazy napříč službami (pozor na N+1 a latenci).

Observabilita a provoz

• Logy: strukturované (JSON), korelační/trace ID propagované přes všechny služby.
• Metriky: golden signals (latence, chybovost, provoz, saturace), byznys metriky (např. úspěšnost objednávek).
• Tracing: distribuované trasování (W3C Trace Context, OpenTelemetry) – vizualizuje závislosti a latence.

Odolnost a řízení selhání

• Circuit breaker a bulkhead izolují chyby, timeouts a retries s exponenciálním backoff a jitterem.
• Rate limiting, queueing, load shedding a hedged requests pro řízení špiček.
• Chaos engineering a game days ověřují připravenost na výpadky.

Bezpečnost: zero-trust a řízení identity

• mTLS mezi službami, rotace certifikátů, service identity (SPIFFE/SPIRE) a krátkodobé tokeny.
• Least privilege v API i databázích, ABAC/RBAC, policy-as-code (OPA).
• Supply chain: podepisované imagy, SBOM, skeny zranitelností, izolace tajemství (KMS/Secrets).

Nasazení, škálování a runtime

• Kontejnery a orchestrátor (Kubernetes): deklarativní nasazení, autoscaling (HPA/VPA), rolling/canary releasy, readiness/liveness pro health.
• Service mesh (Istio/Linkerd): jednotná observabilita, TLS, traffic policy bez změn aplikačního kódu.
• CI/CD: pipeline s testy, bezpečnostními kontrolami, feature flags a rychlou rollback strategií.

Testování v mikroservisním světě

• Kontraktní testy: brání skrytým breaking změnám API.
• Integrační a end-to-end: selektivní scénáře kritických toků; těžké plné e2e nahrazovat synthetic tests a shadow traffic.
• Test data management: deterministická data, seedování, izolace prostředí.

Data a persistence: vlastnictví a polyglotní přístup

• Každá služba vlastní své schéma a publikuje změny skrze API/eventy, nikoli přímým přístupem k cizí DB.
• Polyglot persistence: zvolte typ úložiště podle domény (relace, dokumenty, časové řady, graf).
• Migrace: migrations-as-code, expand & contract strategie, blue-green pro rizikové změny.

Verzování a kompatibilita

• Backward compatibility jako výchozí požadavek; tolerant reader na straně klienta.
• Schema registry a validace (OpenAPI/JSON Schema/Protobuf); řízená deprecace s metrikami využití.

Organizační model a governance

• Platformový tým poskytuje CI/CD, observabilitu, šablony a bezpečnostní baseline.
• Produktové týmy vlastní služby end-to-end (kód, infra, SLO), jasné rozhraní zodpovědností.
• Lightweight governance: katalog služeb, standardy telemetrie, bezpečnostní politiky, ale svoboda volby uvnitř rámce.

Migrační strategie z monolitu

• Strangler Fig: kolem monolitu vzniká nová façade, jednotlivé capability se vyřezávají do samostatných služeb.
• Odloučení dat: anti-corruption layer, replikace/streamování změn (CDC), postupné vypínání tabulek.
• Priorita podle hodnoty: začít u domén s častými změnami, škálovacími problémy či potřebou inovací.

Antipatterny a časté chyby

• Distribuovaný monolit: mnoho služeb, ale těsné vazby, koordinované releasy, sdílená DB – ztráta výhod a nárůst složitosti.
• Předčasná granularita: příliš malá zrna zvyšují režii, latenci a nároky na koordinaci.
• Chybějící observabilita a řízení chyb → obtížná diagnostika a dlouhé MTTR.
• Nejasné doménové hranice: „vyteklé“ modely a křehká API.

Náklady a trade-offy

• Provozní komplexita: více artefaktů, více běhů, nároky na SRE a platformu.
• Latency tax: síťová komunikace, serializace, více hopů – nutná optimalizace toků a cachování.
• Bezpečnostní plocha: více hranic, více tajemství – vyžaduje silnější standardy a automatizaci.

Best practices pro úspěšné mikroservisy

• Začněte DDD a mapou bounded contexts; vyhněte se technickému dělení.
• Prosazujte event-driven integrace, idempotenci a outbox pro spolehlivost.
• Standardizujte telemetrii (logs/metrics/traces) a security baseline (mTLS, secrets, policy).
• Automatizujte CI/CD a platformu (templaty, golden paths); zkraťte lead time bez obětí kvality.
• Definujte SLO/SLI a používejte error budgets pro řízení rychlosti změn.

Závěr: kdy (ne)volit mikroservisy

Mikroservisy přinášejí rychlejší inovace, nezávislé škálování a odolnost, ale za cenu vyšší distribuované složitosti. Jsou vhodné pro doménově pestré systémy s vícero týmy, potřebou rychlých release cyklů a elastického škálování. Pro malé produkty nebo rané MVP může být efektivnější modulární monolit s čistými hranicemi a až následný přechod na mikroservisy podle růstu. Správně aplikovaná mikroservisní architektura – opřená o DDD, eventy, silné provozní standardy a kulturu you build it, you run it – pak představuje robustní základ pro dlouhodobě udržitelné a škálovatelné systémy.