Ještě nedávno bylo působivé, když umělá inteligence doplnila několik řádků kódu. Dnes dokážou AI coding nástroje z jednoduchého zadání vytvořit velkou část webové aplikace, napsat testy, hledat chyby nebo upravovat celý projekt.

Jenže napsáním kódu vývoj aplikace nekončí.

Aplikace potřebuje databázi. Někdy také cache, úložiště souborů, server, síť, DNS, přístupová oprávnění, bezpečné uložení hesel nebo testovací prostředí. A právě tady může zrychlený vývoj znovu narazit.

Kód může vzniknout během desítek minut. Připravení prostředí, ve kterém skutečně poběží, ale pořád vyžaduje další nástroje, znalosti a často také zásah člověka.

Právě proto začíná být stále zajímavější self-service infrastruktura, platform engineering a postupné propojování cloudových nástrojů s AI agenty.

Malý open-source projekt InfraCtrl je dobrým příkladem toho, jak taková budoucnost může vypadat.

Ne proto, že by šlo o nový AWS nebo Vercel. Ale protože na relativně jednoduchém projektu ukazuje zásadní změnu: vývojář už nemusí infrastrukturu ručně stavět. Stačí říct, co potřebuje.

AI zrychlila kód, ale infrastruktura nezmizela

Představme si jednoduchý scénář.

Chcete vytvořit menší webovou aplikaci. Otevřete AI coding nástroj a zadáte:

Vytvoř jednoduchou aplikaci pro správu úkolů. Použij React, API a PostgreSQL.

AI připraví strukturu projektu, frontend, backend i databázové modely.

Jenže PostgreSQL databáze zatím nikde neběží.

Pokud má být aplikace dostupná ostatním, musí někde fungovat také její backend. Potřebuje správně nastavenou síť, bezpečné přihlašovací údaje a pravděpodobně i testovací prostředí.

Najednou se z jednoduchého:

„vytvoř mi aplikaci“

stává:

vytvoř cloudovou databázi,
nastav databázového uživatele,
nakonfiguruj síť,
povol správnou IP adresu,
bezpečně ulož heslo,
nastav backend,
připrav staging,
propojuj jednotlivé služby,
hlídej náklady,
a až prostředí nebude potřeba, nezapomeň ho odstranit.

To všechno je součást infrastruktury.

Pro laika si můžeme software představit jako dům.

Zdrojový kód je projekt domu a materiál. Infrastruktura je pozemek, přípojka elektřiny, voda a cesta.

Můžete mít perfektní projekt domu, ale bez zbytku v něm bydlet nebudete.

Podobně je to se softwarem.

Co je self-service infrastruktura

Ve větší firmě může tradiční proces vypadat přibližně takto:

Vývojář
   ↓
požadavek na infrastrukturu
   ↓
DevOps / cloud tým
   ↓
konfigurace
   ↓
AWS / Azure / GCP
   ↓
hotové prostředí

Vývojář například potřebuje PostgreSQL databázi pro staging.

Založí požadavek, někdo jej musí zkontrolovat, vytvořit databázi, správně nastavit síť a přístupy a předat mu údaje.

Samotný proces přitom může být pokaždé téměř stejný.

Self-service infrastruktura se snaží člověka z těchto opakovaných kroků odstranit.

Vývojář místo ticketu otevře interní portál a vybere například:

typ: PostgreSQL,
prostředí: staging,
velikost: small,
životnost: 7 dní.

Klikne na Create.

Zbytek zajistí automatizace.

Podobný princip dnes CNCF popisuje jako jednu ze základních myšlenek platform engineeringu: vývojář dostává samoobslužnou cestu k nástrojům a infrastruktuře, aniž by musel ovládat celý cloudový stack.

Klasický přístup	Self-service
Ticket	Formulář nebo API
Ruční konfigurace	Automatizace
Čekání na jiný tým	On-demand
Každý požadavek může být jiný	Standardizované šablony
Vývojář nebo DevOps řeší detaily	Platforma nabízí připravený postup

Důležité ale je, že self-service neznamená:

„Dáme každému administrátorský účet do AWS a ať si poradí.“

Ve skutečnosti jde často o pravý opak.

Vývojář dostane omezený počet bezpečných možností, které někdo předem připravil.

Nemůže například vytvořit libovolně drahý server. Dostane volby:

Small / Medium / Large.

Nemusí ručně nastavovat security group. Platforma použije připravenou bezpečnou konfiguraci.

Tomuto přístupu se často říká golden path nebo paved road – předem připravená a doporučená cesta, která umožňuje běžný úkol udělat rychle a správně.

Infrastructure as Code: infrastruktura jako software

Aby bylo možné podobnou infrastrukturu automatizovat, potřebujeme nejprve odstranit ruční klikání.

Právě k tomu slouží Infrastructure as Code, zkráceně IaC.

Místo toho, aby administrátor otevřel AWS Console a postupně naklikal databázi, síť a další parametry, infrastrukturu popíše pomocí konfigurace.

Velmi zjednodušeně může definice databáze vypadat například takto:

resource "aws_db_instance" "database" {
  engine         = "postgres"
  instance_class = "db.t3.micro"
}

Tento příklad neobsahuje všechno potřebné k bezpečnému nasazení databáze. Dobře ale ukazuje princip.

Neříkáme člověku:

Otevři AWS, klikni sem, potom sem a nastav tuto hodnotu.

Říkáme systému:

Chci databázi s těmito vlastnostmi.

Infrastructure as Code nástroj následně zařídí, aby skutečná infrastruktura odpovídala definovanému stavu.

HashiCorp popisuje IaC právě jako způsob správy infrastruktury pomocí konfiguračních souborů místo ruční práce v grafickém rozhraní. Konfiguraci lze verzovat, znovu používat, kontrolovat a automatizovat podobně jako běžný zdrojový kód.

To přináší několik zásadních výhod.

Opakovatelnost

Stejnou infrastrukturu můžete vytvořit znovu.

Verzování

Konfigurace může být uložená v Gitu. Je tak vidět, kdo a kdy něco změnil.

Code review

Změnu infrastruktury lze před provedením zkontrolovat podobně jako změnu programu.

Automatizace

Konfiguraci nemusí spouštět člověk. Může ji spustit CI/CD systém, API nebo později AI agent.

Odstranění

Stejně jako lze infrastrukturu automaticky vytvořit, lze ji také automaticky zrušit.

A právě poslední bod je velmi důležitý například u dočasných vývojových prostředí.

Kde do toho zapadá Terraform

Jedním z nejznámějších nástrojů pro Infrastructure as Code je Terraform.

Terraform dokáže popisovat a spravovat infrastrukturu napříč různými poskytovateli. Může pracovat například s výpočetními instancemi, databázemi, storage, networkingem, DNS nebo dalšími službami.

Typický Terraform workflow obsahuje několik kroků.

Terraform plan nejprve ukáže, co se má změnit.

Například:

+ vytvořit PostgreSQL databázi
+ vytvořit security group
+ přidat síťové pravidlo

Až následné:

terraform apply

změny skutečně provede.

Stejným způsobem lze infrastrukturu také odstranit:

terraform destroy

To je podstatný rozdíl oproti ručnímu vytváření jednotlivých cloudových služeb.

Máme strojově čitelný popis infrastruktury, se kterým mohou pracovat další automatizační nástroje.

A tím se dostáváme k platform engineeringu.

Co je platform engineering

Infrastructure as Code řeší automatizaci infrastruktury.

Vývojář ale pořád nemusí chtít psát Terraform.

Stejně jako řidič nepotřebuje rozumět vstřikování paliva, aby mohl řídit auto, vývojář nemusí znát všechny detaily AWS IAM, VPC, RDS nebo Terraform state, aby získal testovací databázi.

Platform engineering staví nad technickou složitostí další vrstvu.

CNCF jej popisuje jako disciplínu zaměřenou na tvorbu a provoz platforem, které poskytují vývojářským týmům self-service nástroje a standardizované workflow.

Místo:

AWS
IAM
VPC
RDS
Security Groups
Terraform
CI/CD
secrets
monitoring

může vývojář vidět pouze:

Create PostgreSQL database

Technická složitost nezmizela.

Pouze ji někdo vyřešil jednou a připravil z ní bezpečnou službu pro ostatní.

Internal Developer Platform

Výsledkem platform engineeringu bývá něco, čemu se říká Internal Developer Platform.

Je to interní vrstva propojující nástroje, infrastrukturu a firemní procesy.

Vývojář přes ni může například:

vytvořit nový projekt,
nasadit aplikaci,
založit databázi,
vytvořit testovací prostředí,
zobrazit logy,
spravovat konfiguraci,
zjistit vlastníka služby,
otevřít dokumentaci.

Známým příkladem je Backstage, open-source framework původně vytvořený ve Spotify. Backstage kombinuje software catalog, developer portal, dokumentaci a šablony, pomocí kterých mohou týmy standardizovat vytváření nových komponent a služeb.

InfraCtrl je proti Backstage nesrovnatelně menší a jednodušší projekt.

Právě proto je ale užitečný pro pochopení základního principu.

InfraCtrl jako ukázka self-service infrastruktury

InfraCtrl se prezentuje větou:

„Request cloud databases in 5 minutes, not 5 days.“

Jeho cílem je nabídnout jednoduchý portál, přes který si může vývojář vyžádat cloudový resource bez ručního spouštění Terraformu.

Princip je jednoduchý.

Uživatel zvolí typ resource, prostředí a velikost.

InfraCtrl pak automaticky spustí proces, který infrastrukturu připraví.

Zjednodušené schéma vypadá takto:

Vývojář
   ↓
InfraCtrl
   ↓
FastAPI
   ↓
GitHub Actions
   ↓
Terraform
   ↓
AWS
   ↓
PostgreSQL

Frontend tedy sám databázi nevytváří.

Slouží jako jednoduché rozhraní nad celým automatizačním řetězcem.

Podle dokumentace projektu backend vytvoří nový požadavek a GitHub Actions následně spustí Terraform, který vytvoří resource v AWS. Po dokončení se informace o výsledku vrátí zpět do backendu a objeví se v dashboardu.

Uživatel nemusí:

spouštět Terraform,
ručně vytvářet AWS RDS,
řešit každý parametr zvlášť,
ručně zapisovat stav infrastruktury.

To za něj obstará platforma.

A přesně o tom self-service infrastruktura je.

Jak InfraCtrl funguje pod kapotou

Pro technicky zdatnější čtenáře je zajímavější to, co se odehrává pod jednoduchým formulářem.

Projekt používá několik běžně používaných technologií:

Frontend: Next.js
Backend: FastAPI
CI/CD a orchestrace: GitHub Actions
Infrastructure as Code: Terraform
Cloud: AWS
Databáze aplikace: PostgreSQL
Notifikace: Slack

Frontend projektu běží na Vercelu, backend na Railway a infrastruktura vytvářená uživatelem v AWS.

GitHub Actions jako orchestrátor

Po odeslání požadavku backend vyvolá GitHub Actions workflow.

GitHub runner následně provede Terraform.

V praxi tedy GitHub Actions neslouží pouze k testování nebo deployování aplikace, ale také jako prostředník pro vytváření infrastruktury.

Terraform state

Terraform potřebuje vědět, jaké resources již vytvořil.

Proto si udržuje takzvaný state.

InfraCtrl používá pro jednotlivé požadavky oddělené state soubory. Díky tomu systém ví, ke kterému požadavku konkrétní cloudový resource patří.

Bez dlouhodobého AWS access key

Zajímavá je také autentizace GitHub Actions vůči AWS.

Projekt používá OIDC, takže workflow nemusí mít uložený permanentní AWS Access Key a Secret Key. Místo nich získává pro jednotlivé běhy krátkodobé credentials.

Je to ukázka důležitého principu:

automatizace by neměla znamenat horší bezpečnost.

Naopak by měla být navržena tak, aby měla jen oprávnění, která skutečně potřebuje.

Automatické odstranění infrastruktury

InfraCtrl pracuje s dočasnou životností resources.

Výchozí workflow počítá se sedmidenní expirací a pravidelně kontroluje resources, které je potřeba odstranit. Následně může spustit terraform destroy.

To je překvapivě důležitá funkce.

V cloudu totiž často není problém něco vytvořit.

Problém je vzpomenout si, že to už nikdo nepotřebuje.

Zapomenutá testovací databáze nebo server může běžet týdny a dál generovat náklady.

Dočasná neboli ephemeral infrastruktura se proto vytváří jen na dobu, kdy je potřeba, a následně automaticky zmizí.

InfraCtrl zatím není hotová cloudová platforma

Tady je potřeba být k projektu fér.

InfraCtrl je zajímavá demonstrace konceptu, ale zatím bych jej nepovažoval za etablovanou produkční platformu.

Projekt je stále malý a aktivně vyvíjený. GitHub v době psaní článku ukazuje 73 commitů a nulový počet forků.

Ještě důležitější je rozdíl mezi landing page a skutečnou implementací.

Web InfraCtrl aktuálně prezentuje podporu:

PostgreSQL,
Redis,
Amazon S3.

V aktuálním Terraform souboru je ale implementovaná PostgreSQL databáze, zatímco části pro Redis přes ElastiCache a S3 jsou stále zakomentované a označené jako úkol pro budoucí fázi vývoje.

To neznamená, že je projekt nezajímavý.

Jen je důležité rozlišovat mezi:

vizí produktu

tím, co dnes skutečně dělá jeho kód.

Pro nás je InfraCtrl zajímavý především tím, že celý koncept developer self-service ukazuje na relativně malém a pochopitelném projektu.

A teď přichází mnohem zajímavější otázka.

Co když ten formulář přestane vyplňovat člověk?

Co se změní, až infrastrukturu začnou ovládat AI agenti

Dnes může vývojář v podobné platformě vybrat:

PostgreSQL
staging
small
7 dní

Jenže všechny tyto informace může zjistit i AI agent.

Pokud agent analyzuje projekt, může vědět:

že aplikace používá PostgreSQL,
že potřebuje Redis,
že ukládá obrázky,
že jde pouze o staging,
že prostředí potřebujeme dva dny,
jaké environment variables aplikace očekává.

Teoreticky tedy nemusíme říkat:

Vytvoř PostgreSQL small.

Můžeme říct:

Připrav staging prostředí pro tuto aplikaci. Potřebuje PostgreSQL, Redis a object storage. Přístup omez pouze na aplikaci, nastav rozumný rozpočet a prostředí po 48 hodinách automaticky odstraň.

Agent zanalyzuje projekt a použije dostupné infrastrukturní nástroje.

Výsledný workflow může vypadat například takto:

Uživatel
   ↓
AI agent
   ↓
MCP / API
   ↓
interní platforma
   ↓
policy + kontrola
   ↓
Terraform
   ↓
AWS / Azure / GCP

Najednou se dostáváme o krok dál než u klasického vibe codingu.

Nejde pouze o to, že AI vytvoří kód.

AI začne řídit další systémy, které jsou k provozu aplikace potřeba.

Jak do toho zapadá MCP

Jedním ze způsobů, jak může AI komunikovat s externími nástroji, je Model Context Protocol neboli MCP.

MCP lze velmi zjednodušeně chápat jako standardizovaný způsob, jak dát AI aplikaci nástroje.

Model nemusí pouze generovat text.

Může dostat například nástroje:

list_databases
create_environment
get_cost_estimate
run_terraform_plan
deploy_application
destroy_environment

MCP specifikace definuje právě „tools“ jako funkce, které může model objevovat a vyvolávat pro práci s externími systémy.

A propojení MCP a Infrastructure as Code už není jen myšlenkový experiment.

Terraform už má vlastní MCP Server

HashiCorp provozuje oficiální Terraform MCP Server.

Ten může AI poskytovat aktuální informace z Terraform Registry, dokumentaci providerů, moduly nebo policies. Podporuje také nástroje pro práci s HCP Terraform a Terraform Enterprise, například správu workspaces a související operace.

To je důležitý signál.

Neznamená to, že dnes libovolný chatbot dostane neomezenou moc nad firemním AWS účtem.

Ukazuje to ale, že infrastruktura se začíná otevírat stejnému agentickému modelu, který už vidíme u programování.

AI dostane nástroje.

Nástroje mají přesně definované vstupy a oprávnění.

A agent je používá podle cíle, který dostane.

Proč AI nemůžeme jednoduše dát administrátorský účet do AWS

Představa autonomního AI agenta vytvářejícího servery může znít skvěle až do chvíle, kdy mu omylem dovolíme vytvořit stovky drahých instancí nebo smazat produkční databázi.

Proto není správnou cestou:

AI
↓
AdministratorAccess
↓
AWS

Stejně jako by většina firem nedala každému juniornímu vývojáři neomezený administrátorský přístup do produkce.

Agentická infrastruktura bude potřebovat guardrails, tedy jasně definované mantinely.

Může jít například o:

Předem připravené šablony

Agent nevymýšlí konfiguraci libovolně.

Vybere například jeden ze schválených typů PostgreSQL prostředí.

Minimální oprávnění

Nástroj může vytvořit databázi, ale nemůže například měnit firemní IAM administrátory.

Terraform plan

Nejdříve vznikne plán změn.

Teprve po jeho kontrole se změna provede.

Approval

Produkční zásah může vyžadovat potvrzení člověkem.

Limity nákladů

Agent smí vytvořit pouze resources do určité cenové hranice.

Automatická expirace

Testovací infrastruktura sama zanikne.

Audit

Každá operace je dohledatelná.

Tento přístup je důležitý i z pohledu samotného MCP. Jeho specifikace u citlivých nástrojových operací doporučuje zachovat člověka v rozhodovací smyčce a uživateli ukázat, jaké nástroje model používá.

AI tedy nemusí dostat větší moc než člověk.

Dobře navržená platforma jí naopak může dát mnohem přesněji vymezené pravomoci.

Znamená to konec DevOps?

Ne.

Stejně jako AI coding agent automaticky neznamená konec programátorů, self-service infrastruktura neznamená konec DevOps.

Mění se ale typ práce.

Méně důležité bude ručně opakovat:

vytvoř databázi, nastav security group, pošli údaje vývojáři.

Více času se může přesunout k otázkám:

Jak má vypadat bezpečný standard databáze?
Jaké resources smí vývojář vytvořit?
Jaká oprávnění dostane agent?
Jak zabráníme překročení rozpočtu?
Jak zajistíme monitoring?
Jak řešit secrets?
Které změny mohou proběhnout automaticky?
Které musí schválit člověk?
Jak se infrastruktura automaticky uklidí?
Jak všechny kroky auditovat?

DevOps se tak postupně posouvá směrem k platform engineeringu.

Místo člověka, který infrastrukturu ručně vytváří, dostáváme člověka nebo tým, který navrhne systém, jenž ji umí bezpečně vytvářet za ostatní.

To je podstatně škálovatelnější model.

Deset vývojářů nemusí desetkrát řešit stejný problém.

Platform engineer jej může vyřešit jednou a ostatním nabídnout:

Create environment

Od vibe codingu k autonomnějšímu vývoji

Vibe coding ukázal, jak dramaticky lze zjednodušit přístup k programování.

Uživatel nemusí přesně popsat implementaci.

Popíše výsledek:

Chci aplikaci, která dělá toto.

AI překládá záměr do kódu.

Stejný princip se může postupně rozšířit na další vrstvy.

Dnes:

záměr
↓
AI
↓
zdrojový kód

Další fáze může vypadat:

záměr
↓
AI agent
↓
kód
↓
testy
↓
infrastruktura
↓
deployment
↓
monitoring

Aplikace tedy nebude pouze napsaná.

Agent ji bude schopný připravit k reálnému provozu.

Neznamená to, že každý krok musí být plně autonomní.

Právě v infrastruktuře, bezpečnosti a produkčních systémech bude pravděpodobně dlouho důležité kombinovat automatizaci s jasnými pravidly a lidským schválením.

Směr je ale zřetelný.

AI se posouvá od generování obsahu ke skutečnému provádění práce v externích systémech.

A cloudová infrastruktura je pro tento posun přirozeným kandidátem.

InfraCtrl není revoluce. Ukazuje ale velmi zajímavý směr

Samotný InfraCtrl dnes není platformou, která by měnila cloudový trh.

Je to malý open-source projekt, který má před sebou ještě hodně práce.

Jeho význam je jinde.

Na jednom místě spojuje:

jednoduché UI
+
API
+
GitHub Actions
+
Infrastructure as Code
+
AWS
+
automatický lifecycle

Vývojář tedy nemusí přemýšlet nad každým dílčím nástrojem.

Řekne, jakou službu potřebuje, a platforma se pokusí celý proces dokončit za něj.

Dnes tento požadavek vzniká kliknutím ve formuláři.

Zítra jej může vytvořit AI agent.

A právě tady může být další velký krok ve vývoji softwaru.

AI už nemusí pouze napsat aplikaci.

Postupně může získat nástroje k tomu, aby pro ni připravila databázi, infrastrukturu, nasadila ji, sledovala její stav a nakonec nepotřebné prostředí zase odstranila.

Od generování kódu se tak pomalu přesouváme k automatizaci celého životního cyklu software.

Časté otázky

Co je self-service infrastruktura?

Self-service infrastruktura umožňuje vývojářům získat cloudové resources, prostředí nebo služby bez nutnosti zadávat každý požadavek jinému týmu. Běžné operace jsou předem automatizované a dostupné například prostřednictvím interního portálu nebo API.

Co je platform engineering?

Platform engineering je disciplína zaměřená na vytváření interních platforem, nástrojů a workflow, které vývojářům zjednodušují vývoj, deployment a provoz aplikací. Jeho důležitou součástí je developer self-service.

Co je Infrastructure as Code?

Infrastructure as Code je způsob správy infrastruktury prostřednictvím konfiguračních souborů místo ručního nastavování jednotlivých cloudových služeb.

Co je Terraform?

Terraform je Infrastructure as Code nástroj od HashiCorpu, který umožňuje definovat, vytvářet, měnit a odstraňovat infrastrukturu pomocí deklarativní konfigurace.

Je InfraCtrl vhodný pro produkční použití?

InfraCtrl je v současnosti především menší open-source projekt a demonstrace self-service infrastructure workflow. Jeho veřejná prezentace navíc uvádí více typů resources, než kolik jich aktuální Terraform implementace skutečně podporuje. Pro kritické produkční prostředí je proto potřeba projekt posuzovat velmi opatrně.

Může AI agent vytvořit cloudovou databázi?

Technicky ano, pokud dostane nástroj nebo API, které takovou operaci umožňuje. Bezpečný systém by však měl používat omezená oprávnění, schválené konfigurace, audit, limity nákladů a u citlivých operací také lidské potvrzení.

Nahradí AI a platform engineering DevOps?

Spíše změní jeho roli. Opakované ruční úkoly lze automatizovat, ale někdo stále musí navrhovat bezpečnou architekturu, přístupová práva, monitoring, governance, finanční limity a pravidla, podle kterých budou automatizované systémy fungovat.