DevOps je doslovná i obrazná fúze vývoje a provozních záležitostí. Tyto dvě skupiny byly roky oddělené kulturními a znalostními hranicemi, zejména uvnitř větších podniků.
Tato separace byla jasná: Vývojáři se soustředili pouze na kód a provozní tým se zaměřoval na zajištění běhu tohoto kódu. Naprosté oddělení těchto dvou skupin vedlo k dlouhým cyklům QA (Quality Assurance) a nepříliš častým instalacím do produkčního prostředí kvůli obavám z případných výpadků a narušení provozu.
Kombinace organizačního rozdělení, averze k riziku a sekvenčních metod „vodopádu“ dodávek softwaru způsobovala, že mezi většími aktualizacemi softwaru mohl klidně uplynout i více než rok. A v mnoha velkých organizacích zůstává tato praxe dodnes realitou.
V posledních letech je zásadním posunem změna prostředí IT. Vývojáři, unavení z čekání na to, kdy produkce zaktualizuje jejich kód, začali psát software tak, aby automatizoval provozní úlohy. Současně s tím začal provozní personál přispívat svými hlubokými znalostmi a zkušenostmi do vývoje softwaru vytvářeného vývojáři.
Kdysi jasné hranice mezi vývojem a provozem se začínají rozmazávat. To vede ke stále rychlejším životním cyklům aplikací, kratším relacím QA a mnohem většímu počtu nasazení. Dokonce se objevily nové procesy, jako jsou kontinuální integrace a kontinuální nasazování. Mnoho rozsáhlých aplikací vytvořených pomocí metodiky DevOps se nasazuje do produkce několikrát denně namísto několikrát ročně.
Není to jen nějaká nová móda, která brzy pomine. Tento trend směrem k automatizaci během posledních deseti let rostl a odpovídající software i procesy dospěly do velmi zralé podoby. Důsledky DevOps uvnitř podnikových IT je potřeba důkladně posoudit všemi zúčastněnými.
Pokud nechápete, proč má DevOps tak vysokou důležitost, a nepřipravujete se na všechny změny, které přináší, zůstane vaše organizace pozadu.
Vliv na vývojáře
Počátky DevOps lze vysledovat až k nástrojům, jako je Puppet, které se objevily v roce 2005 před vznikem zmíněného pojmu.
Luke Kanies, v té době vývojář Ruby, byl unavený ruční konfigurací Linuxu a ručními úpravami konfiguračních souborů. Snil o takovém způsobu provisioningu a konfigurace systémů podobných Unixu, který by byl programovatelný a reprodukovatelný. Napsal tedy skript v jazyce Ruby, jenž to pro něj dělal, a nazval ho Puppet.
Později se vyvinuly podobné nástroje jako např. Chef, Ansible, SaltStack a další. Kolem každého z těchto nástrojů se vytvořily komunity. Vývojáři a provozní experti přispívali svými znalostmi do balíčků „kuchařek“ a „receptů“, aby umožnily konfigurovat software podobným způsobem bez ohledu na unixovou distribuci.
Pomocí těchto nástrojů může vývojář vytvořit samostatný, programový popis toho, jak aplikaci spustit. Může to zahrnovat všechny závislosti a možnost konfigurace a spuštění v různých unixových distribucích jednoduchým spuštěním skriptu.
To, co kdysi zabralo týdny ručního nastavování a ladění vysoce kvalifikovanými profesionály, lze nyní zvládnout v řádu hodin pomocí skriptu.
Přestože nyní mohou vývojáři nasadit svůj kód rychleji a snáze než dříve, objevil se nový problém. Protože už vývojáři nebyli závislí na svých provozních partnerech, stali se zodpovědnými za zajištění běhu vlastních aplikací.
Tento problém vedl k vývoji dalšího nástroje: platformy poskytované jako služba – ve zkratce PaaS (plPatform as a Service). Přestože byly původně vymyšleny společnostmi Salesforce a Google, vyžadovaly první iterace PaaS, aby vývojáři psali speciální kód, který vázal aplikace k jejich platformě.
Pojem PaaS nebyl popularizován, dokud platforma Heroku neukázala vývojářům způsob, jak spouštět svůj kód s velmi malým počtem významnějších úprav, pokud vůbec byly potřebné.
Systémy PaaS byly založeny na vrcholu automatizačních principů DevOps. Ve skutečnosti většina systémů PaaS dosud používá nástroje DevOps k nastavení a provozu. Rozdíl je v tom, že při použití platformy PaaS jsou v ní provozované aplikace plně spravované.
Aplikaci na platformě PaaS můžete spustit, zastavit, škálovat a monitorovat pomocí rozhraní API. DevOps umožňuje vytvořit sadu nástrojů pro správu vaší aplikace, ale na platformě PaaS jsou pro vás nástroje již připraveny.
Nakonec je nutné poznamenat, že žádná diskuse o DevOps není úplná bez zmínky o Dockeru a kontejnerech. Největší nedostatek platformy PaaS spočívá v tom, že velmi přesně definuje architekturu aplikací.
Pokud chce mít vývojář více kontroly nad prostředím, poskytnou ji kontejnery při zachování rychlosti a agility. Použití platforem Chef či Puppet ke konfiguraci nastavení z nuly může trvat hodiny, a nakonec nemusíte získat zcela přesnou kopii.
Při použití kontejneru může vývojář reprodukovat prostředí Linuxu nebo Windows za zlomek vteřiny a mít jistotu, že je to přesná kopie.
Přijetím a vylepšením těchto nástrojů DevOps získali vývojáři během let obrovský nárůst produktivity. Blíží se konec doby, kdy vývojáři vůbec nevnímali problémy provozu a škálování, protože se umění provozu aplikací začíná integrovat do plně automatizovaného počítačového kódu.
Vliv na provoz
Přestože revoluci DevOps začali vývojáři, k jejímu konečnému přijetí byli nezbytní správci systému a provozní experti. Koneckonců i jim tyto nástroje pomáhají získávat efektivitu při práci. Ve skutečnosti nástroje DevOps dramaticky změnily způsob práce a vytvořily moderní agilní provozní prostředí, za které jsou provozní týmy zodpovědné.
Před érou DevOps měli správci systémů a provozní týmy na starost udržovat běh jednotlivých aplikací ve velkém měřítku. To zahrnovalo tak rozmanité činnosti, jako jsou ladění databází a webových serverů, nastavení vyvažovačů zátěže, správu zabezpečení, správu systémů vyrovnávací paměti cache a mnoho dalších.
DevOps umožňuje vysoký stupeň standardizace, vytvoření efektivních způsobů nasazení, konfigurace a spouštění mnoha serverů s pomocí několika nástrojů namísto spoléhání se na zásah člověka.
Úlohou provozního týmu je stále více zavádět a udržovat automatizovanou aplikační službu na vyžádání, jako jsou PaaS nebo cluster kontejnerů systému Linux nebo Windows. Vývojáři potom nasadí a upraví rozsah jednotlivých aplikací do aplikační sítě, jejíž provoz a škálování ponechají na provozních týmech.
Platformy a nástroje DevOps vytvořily vyrovnávací a tlumící prvek, který umožňuje vývojářům a provozním týmům pracovat nezávisle na sobě namísto v uzavřených krocích.
Před příchodem těchto nástrojů se používala sekvenční aplikační návaznost. Jednotlivé aplikace by musely mít individuální požadavky na provoz, pořízení a na nakonfigurování serverů, než by je bylo možné nakonec nasadit.
S příchodem nástrojů DevOps vývojáři mohou používat kvóty, kde mohou v určitých mezích zajišťovat nasazení na vyžádání a v reálném čase. Provozní týmy se již nemusejí starat o nasazování jednotlivých aplikací.
Stále zajišťují hardware, nastavují a spravují servery, ale dělají to ve větším měřítku, než je aplikační jednotka. Jejich odpovědnost spočívá ve správě automatizovaných sítí DevOps, ke kterým mají vývojáři lepší přístup.
Tento technologický vyrovnávací a tlumící prvek rozpojil sekvenční životní cyklus aplikací a umožnil vývojářům a provozním týmům více spolupracovat. Může se zdát proti všemu očekávání, že by rozpojení týmů mohlo přinést jejich těsnější spolupráci, ale nejrychlejší způsob byl dát dva kuchaře do stejné kuchyně.
Umožnění vývojářům pracovat v rámci dobře definovaného systému (například vytvářet kód uvnitř sítě), zatímco provozní tým pracuje vně kontejneru, zajišťuje, že mají kuchaři oddělené odpovědnosti.
Území mezi vývojáři a provozními týmy – samotné nástroje DevOps – se stalo ekosystémem spolupráce, kde přestává být jasný rozsah odpovědnosti. Provozní týmy mají hluboké znalosti osvědčených postupů pro provoz a údržbu komplexních softwarových systémů. Vývojáři umějí učit počítače, jak implementovat hluboké provozní znalosti bez zásahu člověka.
Zaměstnavatelé stále častěji hledají programátory s provozními zkušenostmi a správce systémů se zkušeností programování. Obecně však je největším dopadem DevOps na provozní týmy to, že jsou stále více pověřované provozem aplikační sítě, která vývojářům poskytuje automatizované volby nasazení na vyžádání.
Poctivý kruh
Slavná slova Marca Andreessena „svět je pojídán softwarem“ jsou stejně pravdivá pro tvorbu a provoz aplikací jako pro zavolání taxíku či pronájem hotelu. Desítky let byla úloha provozu aplikací polem působnosti elitní skupiny vysoce vyškolených geniálních správců systémů. Nyní se z toho stává běžná záležitost.
Většina znalostí byla nedokumentovaná a předávaná slovně jako folklór, z generace na generaci. Konfigurační soubory měly různé nezvyklé formáty. Někdy byly tyto formáty tak zvláštní, že to vyžadovalo kompilaci konfiguračních souborů do dalších konfiguračních souborů. Přesná znalost, jak a proč tyto soubory vyladit, je pro většinu lidí záhadou a rozumí tomu jen málokdo.
DevOps se stal způsobem, jak zaznamenat všechny takové důvěrné znalosti provozu do otevřených standardů, které lze v průběhu času dokumentovat a sledovat. Tyto znalosti se mohou naprogramovat do logiky používané k vytváření platforem aplikačních sítí jako PaaS a clustery linuxových kontejnerů a lze je iterovat a sdílet s ostatními.
Jak se vývojáři zlepšují v oblasti provozu a správci systémů začínají programovat, začnou jejich odpovědnosti postupně splývat. Hranice se již rozmazávají, a to otevírá dveře novým nástrojům pro spolupráci mezi skupinami, které původně spolupracovaly jen minimálně.
Dalším příkladem tohoto vývoje je kontejnerová platforma Docker. GitHub poskytl vývojářům otevřené prostředí ke sdílení kódu s ostatními a k mnohem snadnější spolupráci, než tomu bylo dříve. Docker Hub otevírá stejný druh spolupráce pro správce systémů, a tím přináší novou renesanci do oblasti nasazení a správy infrastruktury.
DevOps se bude dále vyvíjet. Vždy se objeví nějaký nový nástroj, další framework nebo skvělý trend, ale základem, který je všechny spojuje dohromady, je skutečná automatizace softwaru. Stejně jako automatizace přinesla kontinuální integraci a kontinuální dodávání do vývoje softwaru, přináší programovatelnou infrastrukturu do provozu.
Tento příspěvek vyšel v Computerworldu 12/2017. Časopis (starší čísla i předplatné těch nadcházejících) si můžete objednat na adrese našeho vydavatelství.
PŘEDPLATNÉ
ČLÁNKY DO MAILU