Written by Obvykle něco nastavíme a pak zdokumentujeme (a většinou to pozdější realitě moc neodpovídá). Co to otočit? Co mít dokumentaci spustitelnou a definovat jí požadovaný stav aplikací, systémů, logické i fyzické infrastruktury?
Desired state na tričko
Myslím, že je dobré zkoušet klíčové myšlenky formulovat tak, aby se to vešlo jako nápis na tričko – klidně oboustranně. Dnešní téma by se možná dalo artikulovat takhle:
Neříkej mi co mám dělat !
Řekni mi co chceš.
Zdá se mi, že celé IT směřuje ke konceptům, kdy se definuje cílový stav (chci hodinky) a roboti do něj IT dovedou (sestaví ozubená kolečka). Tato definice (manifest, šablona, recept, kniha) je čím dál více ve tvaru, který robot umí dobře zpracovat, ale přitom je to pro člověka dobře uchopitelné – typicky nějaký YAML nebo JSON, občas kód či pseudokód. Protože nejde o nějaký binární formát je ideální držet to ve versioning systému jako je Git a mít tak přehled o změnách, vývoji a řešit koordinaci a spolupráci v týmech (třeba s Gerritem). Výsledkem je vlastně spustitelná dokumentace – něco, co není důsledkem lidské činnosti v infrastruktuře, ale naopak jde o lidskou činnost v designu jejímž důsledkem je cílový stav infrastruktury.
Roboti dělají podstatně méně chyb, než lidé, takže výsledek má tendenci vždy dopadnout stejně špatně nebo stejně dobře. Získáváme dokonalou konzistenci. Přijde doba, kdy budeme mít v IT striktní pravidla zakazující lidem sahat robotům do řízení, tedy měnit ručně stav aplikací, systémů či infrastruktury. Potřebujete jinou topologii, jinou verzi knihovny, jiný počet balancovaných instancí, aplikovat patch, nastavit bezpečnost či zvětšit datový prostor či přidat síť? Žádné SSH a hurá bušíme. Půjdete na začátek, do manifestu (definice cílového stavu) a tam to změníte. Roboti pak potřebné kroky provedou s chladnou přesností. Znamená to konec lidí a ztráty na pracovních místech? Jsem přesvědčen, že ne, protože celková komplexita IT nikdy neklesá.
Zákon zachování složitosti IT
Člověk, který umí zvládat složitost, je užitečný a dobře zaplacený. Zjednodušování tak může vnímat jako špatnou zprávu – přijde o místo? V historii IT se neustále snažíme komplexitu odstraňovat. Vezměte například jaké bylo terno umět namontovat a nainstalovat server (kompletace komponent, nastavení jumperů a BIOSu, instalace do racku, nahrání OS z cédéčka v zimě datového centra za současného cvičení s přehazování CD s OS a CD s drivery, …). Dnes ho většinou získáte virtuální na kliknutí a i zprovoznění nového fyzického systému je v zásadě hračka – dáte do racku, připojíte a jdete do kanclu udělat zbytek (pokud to za vás neudělá třeba Cobbler). Co se ale stalo ve skutečnosti? Snížili jsme komplexitu instalace serveru, ale tím jsme celé IT “odbrzdili”. Teď ho můžeme využívat víc a taky to děláme – ale tím jsme narazili na nové problémy, tedy složitost, o které jsme dříve ani netušili, protože jsme byli zabrzděni v předchozí éře.
V IT tedy neustále snižujeme složitost. Výsledkem je odbrzdění, které přinese novou složitost někde jinde. Celková poptávka po expertíze by se tak měnit neměla. Kdo je v ohrožení? Ten kdo si drží jednu znalost a odmítá ji rozvíjet dál (ale i takové lidi IT potřebuje, byť v podstatně menších počtech, viz poptávka po Cobol programátorech). Člověk od serverů je dnes virtualizačním adminem a zítra bude ovládat IaaS. Systémák se stane expertem na Chef/Puppet/Ansible. Klasický storage specialista, který dnes řeší Fibre Channel a pole se možná stane odborníkem na object store a Hadoop (ve finále jde přece stále o to samé – o data).
Je to už realita?
Je a příkladů najdete spousty v mnoha různých oblastech. Aplikace, jejich potřeby, služby a instance definujete v manifest souboru pro Cloud Foundry PaaS (HP Helion Development Platform). Stav systému je v knize nebo receptu v Ansible, Chef, Puppet nebo Saltstack. Logickou infrastrukturu, tedy síť, router, firewall, balancer, VPN, VM a storage popíšete v OpenStack Heat šabloně. Fyzickou infrastrukturu můžete popisovat a automatizovat například v HP OneView nebo síť přes SDN a tak podobně. Desired state principy najdete i na méně očekávaných místech. Například Aruba Instant cluster (cluster bezdrátových bodů) je totéž – definujete SSID a bezpečnostní a prioritizační pravidla pro jednotlivé aplikace a nezajímá vás, kolik a jakých AP modelů bude v clusteru. V ClearPass deklarujete bezpečnostní politiku typu “Tomáš má v pondělí přístup na CRM” a řešíte to jako roli, nejste omezeni na jeden konkrétní mechanismus vynucení. OpenSwitch konfigurace je deklarativní JSON (nikoli konfigurace v klasickém prvku, která je vlastně imperativním batch) – čili v OpenSwitch nezáleží na pořadí (nemusíte dodržet sekvenci vytvoř VLAN, vytvoř nad ní L3 rozhraní, přiřaď IP, nastav OSPF náklady, …)
