Digitální suverenita. Ještě před dvěma lety to bylo téma pro vládní stratégy a právníky specializující se na GDPR. Dnes je to otázka, kterou dostáváme od IT manažerů, CTO i systémových administrátorů z finančního sektoru, energetiky i telekomunikací: Kdo skutečně kontroluje naši infrastrukturu? Co se stane, když se změní podmínky u našeho cloudového poskytovatele? Jak dokladujeme soulad s NIS2 nebo AI Actem?

Moderní architektura založená na microservices přináší značnou provozní složitost. Jednotlivé služby jsou sice malé a nezávislé, ale ve větším systému jich mohou být desítky až stovky. Každá z nich musí řešit bezpečnost, vyvažování zátěže, monitoring a řízení provozu.
Zatímco u monolitické aplikace stačilo tyto oblasti řešit jednou, v microservices architektuře je nutné je řešit pro každou službu zvlášť. Kubernetes sice poskytuje základní podporu (např. objekt Service, L4 load balancing nebo service discovery), ale neřeší pokročilé scénáře, jako jsou:

• metriky na L7 úrovni,
• inteligentní směrování provozu,
• rate limiting,
• circuit breaking.

Samotný Kubernetes proto nestačí ke spolehlivému provozu většího počtu microservices. Jak systém roste, stává se jeho správa a observabilita stále obtížnější. Zde přichází ke slovu service mesh – dedikovaná infrastruktura, která řeší komunikaci mezi službami transparentně a centrálně, bez nutnosti zásahů do aplikačního kódu.

Pojďme se v článku seznámit s použitím Red Hat OpenShift Local na reálném use-case. Zároveň si odpovíme na otázku, zda jeho použití naplňuje prvky antického dramatu.

Na našich dobrodružných plavbách s kontejnerovým plavidlem RHT OpenShift (z loděnice dodavatele Red Hat) se posádka ELOS Navy setkává s velmi častým dotazem – "Jak a/nebo kde jednoduše začít s OpenShiftem?". Ať už je to důsledek absolvovaného školení, Q&A po pre-sale workshopu, či jen z ryzí zvědavosti.