Mikroservisy a kontejnerizace

Proč mikroservisy a proč právě teď

Architektura mikroservis rozkládá aplikaci na menší, samostatně nasaditelné a škálovatelné služby, které spolu komunikují přes dobře definovaná rozhraní. V kombinaci s kontejnerizací (OCI image) a orchestrací (Kubernetes) umožňuje rychlé releasy, nezávislé nasazování, lepší izolaci chyb a efektivní využití zdrojů. Cena za tuto flexibilitu je komplexita: řízení distribuovaného systému, observabilita, síťová spolehlivost a bezpečnost.

Principy mikroservis: hranice, nezávislost a kontrakty

• Jedna odpovědnost: každá služba je orientovaná na malé business capability (např. „fakturace“), ne na technickou vrstvu.
• Silné hranice: kontrakty API jsou explicitní; data jsou vlastněna službou (data ownership) a nejsou sdílena na úrovni databáze.
• Nezávislé nasazování: každá služba má svůj životní cyklus, CI/CD a verzi.
• Odolnost vůči chybám: defaultem je předpoklad selhání sítě i závislostí; implementují se retries, timeouts, circuit breaker a bulkheads.

Doménový návrh a dekompozice

Mikroservisy by měly odrážet doménové hranice (DDD): bounded context určuje slovník a pravidla dané domény. Dekompozice „podle databázových tabulek“ vede k těsnému propojení; vhodnější je dělit podle use-case a toků hodnoty. Klíčové je vyvážit granularity: příliš malé služby zvyšují režii provozu, příliš velké snižují benefity nezávislosti.

Datová vrstva: jedna služba, jeden zdroj pravdy

• Polyglot persistence: každá služba si volí databázi dle potřeby (relace, dokumenty, časové řady, grafy).
• Integrace dat: místo sdílené DB používejte eventy (CDC, log změn) a materializované pohledy v konzumentech.
• Transakční konzistence: vyhýbejte se distribuovaným 2PC; upřednostněte Saga pattern (choreografie/orchestrace) s kompenzačními kroky.

Komunikace: synchronní vs. asynchronní

• Synchronní (HTTP/gRPC): vhodné pro request-response a nízkou latenci; nutné definovat timeouty, idempotenci, backoff.
• Asynchronní (event bus, streamy): decoupling producentů a konzumentů, vyšší odolnost vůči špičkám; vyžaduje event schema, verzování a dead-letter fronty.
• Contract-first: OpenAPI/AsyncAPI/Protobuf jako zdroj pravdy, generování klientů a validátorů.

Kontejnerizace: immutable artefakty a přenositelnost

• OCI image: reprodukovatelné buildy (multi-stage), minimální base image (distroless, alpine), oddělený uživatel (ne root), read-only root FS.
• Supply chain: SBOM (CycloneDX/SPDX), skenování zranitelností, podepisování image (cosign), provenance z CI.
• Konfigurace: 12-factor zásady – konfigurace přes proměnné, externalizované tajemství (Vault/KMS), entrypoint bez shell hacků.

Orchestrace v Kubernetes: od podů ke službám

• Základní objekty: Pod (běh kontejnerů), Deployment (repliky a rollout), Service (L4 load-balancing), Ingress/Gateway (L7 routing).
• Škálování: HPA (CPU/mem/benčmark metriky), VPA pro doporučení, KEDA pro event-driven škálování.
• Úložiště: CSI pro persistent volumes, třídy storage; stateful služby přes StatefulSet, PodDisruptionBudget.
• Síť: CNI (Calico/Cilium), NetworkPolicy pro izolaci; pod-to-pod šifrování (IPsec/WireGuard) podle CNI.

Service Mesh: spolehlivost a bezpečnost na síťové vrstvě

Proxy sidecar (např. Envoy) přidává mTLS, traffic shaping, retry/circuit breaker, telemetrii a politiky bez změny aplikačního kódu. Opatrně s overheadem: zvažte ambient či sidecarless varianty, případně mesh jen pro kritické domény.

Observabilita: logy, metriky a trasování

• Metriky: RED/USE (rate, errors, duration / utilization, saturation, errors), standard OpenMetrics; centralizace do TSDB a alerting na SLO/SLI.
• Logy: strukturované JSON, korelační ID napříč službami; retenční a maskovací pravidla.
• Tracing: OpenTelemetry pro end-to-end latence; sampling (tail-based) a baggage pro obchodní korelace.

Resilience a řízení provozu

• Timeout, retry, jitter: vždy definujte a testujte – defaulty platí jen v dokumentaci.
• Circuit breaker: izolujte kaskádové selhání; fallbacky a bulkhead izolace vláken/poolů.
• Chaos engineering: řízené výpadky (síť, uzly, závislosti) s měřitelným cílem (SLO).

Bezpečnost cloud-native: od kódu po runtime

• Shift-left: SAST/SCA/IaC skeny v CI; blokace kritických CVE.
• Runtime: seccomp/AppArmor, drop capabilities, read-only FS, non-root, pod security standardy, síťové politiky, eBPF detekce anomálií.
• Politiky: OPA/Gatekeeper nebo Kyverno – vynucování podpisů image, labelů, limitů zdrojů a tajemství.
• Identity: workload identity (SPIFFE/SPIRE, cloud OIDC), rotace klíčů, nulová důvěra (Zero Trust).

CI/CD a GitOps pro mikroservisy

• Pipeline: lint → build → test → SBOM → sign → push → deploy; matice verzí a paralelizace.
• Manifesty: deklarativní správa (Helm/Kustomize); GitOps (Argo CD/Flux) jako zdroj pravdy – auditovatelné změny, automatická rekonsolidace.
• Release strategie: blue-green, canary s metrikami, feature flags; automatický rollback podle SLO.

Konfigurace, tajemství a multitenance

• Config: ConfigMap/Secrets, šablonování a verzování; prostředí oddělená namespace a RBAC.
• Tajemství: integrace s Vault/KMS, sealed secrets; žádná tajemství v image ani v Git repozitáři v otevřené podobě.
• Multitenance: limity/quoty, network policy, oddělené ingress/gateway, resource requests/limits a PDB pro férové plánování.

Testování v distribuovaném světě

• Contract testing: ověřuje kompatibilitu producent-konzument (pact-like).
• Ephemeral prostředí: per-branch náhledy (preview apps) – rychlá zpětná vazba.
• Load/chaos testy: realistická data, testy latencí, špiček a degradace závislostí.

Výkon a náklady

• Profilace: APM, pprof/ebpf, flame-graphs; identifikace „zdi“ (CPU, I/O, locky, GC).
• Resource shaping: správné requests/limits zamezí thrashingu a noisy neighbor jevům.
• Nákladové metriky: cost per request, per tenant; práh autoscalingu podle obchodních metrik (KEDA + Prometheus).

Antipatterny a jak se jim vyhnout

• Distribuovaný monolit: množství služeb, ale těsné vazby a koordinované releasy – lék: kontrakty, asynchronní eventy, nezávislé data store.
• Chatty služby: příliš mnoho synchronních volání na kritické cestě – lék: aggregation, CQRS, caching, bulk API.
• Shared DB: obcházení API sdílenou tabulkou – lék: vlastnictví dat a CDC/eventy.
• „Jeden klastr pro všechno“: míchání rizik a priorit – lék: izolace prostředí, node pools, taints/tolerations.

Stateful mikroservisy a transakce

Stav je nevyhnutelný: StatefulSet s persistentním storage, readiness/liveness/ startup proby, řízení pod anti-affinity, topology spread, záložní repliky a správná pod disruption strategie. Transakce řeší Saga, idempotentní operace a pořadová semantika v event streamech.

Platform engineering a developer experience

• Golden paths: kurátorské šablony (Backstage/portál), přednastavené pipeline a manifesty.
• Self-service: katalog služeb, standardizované „kola“ (buildpacky), internal developer platform s bezpečnými defaulty.
• Governance: policy-as-code, SLO-as-code, jednotné telemetrické standardy a dokumentace.

Edge případy: hybrid/multi-cloud a suverenita dat

Pro distribuovanou infrastrukturu jsou klíčové federace klastrů, service discovery napříč regiony, global traffic management a řízení latence. Suverenita dat vyžaduje lokalitu storage, geo-fencing a šifrování v klidu i přenosu.

Checklist pro nasazení mikroservis v kontejnerech

• Jasné hranice domén a kontraktů (OpenAPI/AsyncAPI/Protobuf), verzování a backward compatibility.
• OCI image: multi-stage, ne-root, read-only, SBOM, podpis, sken zranitelností.
• Kubernetes: správné requests/limits, readiness/liveness, NetworkPolicy, PDB, HPA/VPA/KEDA.
• Bezpečnost: pod security, seccomp/AppArmor, OPA/Kyverno, workload identity, tajemství mimo image.
• Observabilita: metriky RED/USE, strukturované logy, OpenTelemetry trace, SLO/alerty.
• CI/CD a GitOps: automatizované buildy, canary/blue-green, rollback na základě SLO, audit trail.
• Odolnost: timeouty, retry s jitterem, breaker, bulkheads, chaos testy.

Závěr: mikroservisy jako organizační i technický závazek

Mikroservisy a kontejnerizace přinášejí rychlost a škálovatelnost, ale vyžadují disciplinu v návrhu kontraktů, datové architektuře, bezpečnosti a observabilitě. Úspěch není dán počtem služeb, nýbrž kvalitou hranic, automatizací a provozní zralostí. Vytvoření stabilní platformy, standardizovaných cest pro vývojáře a měřitelných SLO transformuje komplexitu cloud-native prostředí v konkurenční výhodu.