Většina firem si myslí, že když najme externího dodavatele na DevOps automatizace, získá tím hotové řešení. Ve skutečnosti ale často jen vymění jeden problém za jiný - závislost na konkrétním dodavateli. Jakmile ten odejde nebo změní podmínky, vaše infrastruktura se stane černou skříňkou, do které nikdo z vašich lidí nemá klíč. Pražská společnost Vesmus přichází s přístupem, který tuto past obchází: veškerá konfigurace serverů, sítí a bezpečnostních pravidel žije přímo ve vašem Git repozitáři.
Tento model není jen o technické eleganci. Je to otázka vlastnictví a kontroly. Pokud je infrastruktura definována kódem (tzv. Infrastructure as Code, zkráceně IaC), který máte pod svou správou, nejste rukojmím žádného konzultanta. Můžete měnit lidi, nástroje i cloudové providery, aniž byste museli začít od nuly. Podívejme se, proč je tento přístup pro firmy dlouhodobě výhodnější než tradiční outsourcing, kde dodavatel drží veškeré know-how u sebe.
Konec vendor lock-inu díky standardním nástrojům
Když dodavatel staví infrastrukturu ve svém vlastním systému nebo používá proprietární nástroje, které zná pouze on, vzniká riziko takzvaného lock-inu. To znamená, že vás „zamkne“ u jeho služeb, protože migrace by byla příliš nákladná a složitá. Tým Vesmus se tomuto modelu vyhýbá tím, že pracuje výhradně s otevřenými a průmyslově standardními technologiemi. Jde například o Terraform pro správu infrastruktury, Ansible pro konfiguraci systémů nebo Kubernetes pro orchestraci kontejnerů.
Důvod je prostý: tyto technologie znají tisíce inženýrů po celém světě. Pokud váš současný tým potřebuje pomoc nebo chcete změnit dodavatele, najdete někoho, kdo těmto nástrojům rozumí, během několika dní. Naopak, pokud jste závislí na specifickém nastavení jednoho dodavatele, hledání náhrady může trvat měsíce a stát majlant. Podle týmu Vesmus je cílem vytvořit takovou infrastrukturu, na kterou během roku skoro nemyslíte, protože běží hladce a je dobře zdokumentovaná. A aby to fungovalo, musí být dokumentace a konfigurace dostupná všem, kteří ji potřebují, tedy vám.
| Vlastnost | Tradiční outsourcing (Dodavatel drží kód) | Model Vesmus (Kód v repozitáři klienta) |
|---|---|---|
| Vlastnictví kódu | Dodavatel | Klient |
| Riziko lock-inu | Vysoké | Nízké |
| Přenos know-how | Omezený, často formou ústní předávky | Plný, prostřednictvím Git historie a README souborů |
| Možnost změny dodavatele | Složitá a drahá | Jednoduchá, stačí mít přístup k repozitáři |
| Transparentnost | Nízká, klient vidí jen výsledek | Vysoká, klient vidí každou změnu v reálném čase |
Infrastruktura jako kód: Co to vlastně znamená pro vaši firmu?
Představte si, že místo klikání v grafickém rozhraní cloudu píšete textové soubory, které popisují, jak má vaše IT prostředí vypadat. Napište tam: „Potřebuji virtuální stroj s touto velikostí, s tímto operačním systémem a s přístupem na port 443.“ Tento soubor pak uložíte do Gitu. Když ho spustíte, automatizovaný proces vytvoří vše podle zadání. Pokud něco pokazíte, vrátíte se k předchozí verzi souboru jedním příkazem.
Právě tento princip stojí za tím, proč Vesmus doporučuje ukládat veškerou konfiguraci do repozitáře klienta. Nemusíte vědět, jak přesně funguje Terraform nebo Ansible pod kapotou, abyste ocenili výhody tohoto přístupu. Důležité je, že máte kontrolu nad tím, co se děje s vaší infrastrukturou. Každá změna je zaznamenána, kdo ji udělal, kdy a proč. To je zásadní nejen pro ladění chyb, ale také pro compliance a audity.
Mnoho firem se bojí, že budou muset najímat drahé specialisty, aby tento kód udržovali. Realita je však často opačná. Díky tomu, že se konfigurace řídí stejnými pravidly jako vývoj aplikací, mohou ji spravovat i běžní vývojáři nebo IT administrátoři, kteří mají základní znalosti Gitu. Vesmus navíc nabízí školení a workshopy, které pomáhají interním týmům tyto dovednosti rychle získat.
Bezpečnost a compliance jako nedílná součást kódu
V regulovaných odvětvích, jako je fintech nebo e-commerce, je dodržování předpisů (GDPR, PCI DSS, PSD2) kritické. Tradičně se bezpečnost řeší až na konci projektu, což vede k pozdním opravám a stresu. Při přístupu „infrastructure as code“ jsou bezpečnostní pravidla napsána přímo v konfiguraci. Pokud chcete zakázat veřejný přístup k databázovému serveru, napíšete to do kódu. Tenhle pravidlo pak platí pro každý nový server, který vytvoříte.
Tým Vesmus má zkušenosti s přípravou dokumentace pro regulační orgány, jako jsou FCA ve Velké Británii nebo ČNB v Česku. Klíčové je, že auditorka nemusí procházet stovky screenshotů z cloudového portálu. Stačí jí podívat se do Git repozitáře a ověřit, že nastavení odpovídá požadavkům. Compliance se tak stává automatickým procesem, který se udržuje sám. To šetří čas a snižuje riziko lidských chyb, které jsou při manuálním nastavování časté.
Proč je jednoduchost lepší než složitost
Na trhu panuje trend používat čím dál složitější architektury. Kubernetes je skvělý nástroj, ale pro malou startupovou aplikaci může být zbytečnou zátěží. Vesmus se hlásí k filozofii budování nejjednodušší možné infrastruktury, kterou si klient dokáže udržitelně provozovat. Ne vždy potřebujete mikroservisy a service mesh. Někdy stačí pár dobře nakonfigurovaných serverů a jasně definované CI/CD pipeline.
Tento pragmatický přístup pomáhá vyhnout se tzv. „over-engineering“, tedy zbytečnému komplikování systému. Jednodušší infrastruktura znamená méně míst, kde se může něco pokazit, a nižší náklady na provoz. Když se rozhodnete pro komplexnější řešení, jako je právě Kubernetes, mělo by to být proto, že to vaše aplikace reálně potřebují, ne proto, že je to módní. Vesmus vám pomůže toto rozhodnutí udělat na základě dat a reálných potřeb vašeho byznysu, nikoliv na základě technologických hype cyklů.
Co dělat, když už máte infrastrukturu u jiného dodavatele?
Pokud aktuálně spolupracujete s dodavatelem, který drží veškerou konfiguraci u sebe, neznamená to, že jste v pasti navždy. Migrace na model s vlastními repozitáři je možná a často se vyplatí. Prvním krokem je audit současného stavu. Zjistíte, co přesně máte nastaveno a jaké jsou závislosti. Následně se postupně převádí ruční konfigurace do kódu.
Tento proces lze provést iterativně. Začnete u nové funkcionality, kterou budete stavět novým způsobem, a staré části necháte běžet, dokud to bude nutné. Postupně se tak dostanete k plné vlastnické práva na svou infrastrukturu. Důležité je komunikovat s dodavatelem o tom, že chcete mít přístup ke konfiguracím. Transparentnost je hodnota, kterou by měl každý seriózní partner akceptovat. Pokud se brání, je to signál, že jejich model je postaven na vaší závislosti, nikoliv na hodnotě, kterou přinášejí.
Musím mít vlastní vývojáře, abych mohl využívat infrastrukturu jako kód?
Ne nutně. Zatímco初期 fáze vyžaduje specialisty, kteří kód napíšou, údržba je často zjednodušena natolik, že ji zvládne i běžný IT administrátor. Navíc, mnoho nástrojů nabízí grafická rozhraní pro náhled na stav infrastruktury, takže nemusíte číst celý kód, abyste pochopili, co se děje.
Jak je to s bezpečností mého Git repozitáře?
Git repozitář je zabezpečen stejně jako ostatní vaše citlivá data. Používá se šifrování při přenosu i v klidu, přístupová práva se řídí rollemi uživatelů a lze zapnout dvoufázové ověření. Pro firmy s vyššími nároky existují enterprise verze GitHubu nebo GitLabu, které nabízejí pokročilé bezpečnostní funkce a audit logy.
Co když dodavatel neposkytne kompletní zdrojový kód?
Je důležité mít tuto situaci upravenou ve smlouvě ještě před začátkem spolupráce. Ideální je, aby bylo jasné, že veškerá vytvořená konfigurace a skripty patří klientovi. Pokud již spolupracujete, zkuste se domluvit na předání aktuálního stavu konfigurací. V krajním případě lze některé části infrastruktury zpětně extrahovat pomocí API cloudových providerů, ale je to pracnější než mít původní kód.
Je tento přístup vhodný pro malé firmy?
Ano, zejména pro firmy, které chtějí škálovat. I když má firma jen jeden web, investice do IaC se vyplatí, protože připraví půdu pro budoucí expanzi. U velmi malých projektů může být počáteční nastavení náročnější, ale dlouhodobě šetří čas a peníze díky automatizaci rutinních úkolů.
Jak dlouho trvá migrace na vlastní repozitáře?
Záleží na velikosti a složitosti současné infrastruktury. Jednoduché projekty lze migrovat během několika týdnů, zatímco rozsáhlejší systémy mohou vyžadovat několik měsíců práce. Klíčem je postupný přístup, kdy se migrace provádí po částech, aby nedošlo k přerušení provozu.