Když v cloudu, tak DevOps. Proč?

 

DevOPs je slovo, o kterém se aktuálně hodně mluví, píše a v IT personalistice dnes takřka neexistuje jiná než DevOps pozice. Co vlastně tento termín znamená? Co si pod ním představit? Odpovědi najdete v následujícím stručném článku.

Lukáš Křížek

 

Samotný pojem DevOps vznikl ze slov Development (vývoj) a Operation (provoz). Na internetu můžeme najít nespočet jeho možných výkladů, nicméně všechny se shodují na několika základních charakteristikách. DevOps je nadstavba metodiky agilního vývoje, která při správné implementaci:

• usnadňuje práci uvnitř vývojových týmů,
• urychluje integraci nových aplikací či jejich funkcionalit do cloudu,
• zlepšuje komunikaci mezi týmy vývojářů a týmů na straně Operations,
• v neposlední řadě také zdokonaluje kontrolu kvality doručovaného produktu.

 

Vývoj aplikací bez DevOps a bez růžových brýlí

Dalo by se namítnout, že tato metodika, DevOps, je zbytečná, protože týmy mezi sebou komunikují (možná i nad rámec pracovních procesů), nové aplikace jsou v produkci přesně podle plánu a vše funguje naprosto bezchybně i bez DevOps.

Ale co když odložíme růžové brýle a zeptáme se uživatelů výsledného produktu na jejich pocity z používání poskytované aplikace. Jsou spokojení i oni? Jsou jejich požadavky a problémy nějak řešeny? Je možné zpětně zjistit, co se dělo s aplikací? Jak rychlá byla odezva na problémy a co přesně bylo posunuto do produkčního prostředí?

A pokud se na naše ne-devopsové prostředí podíváme skutečně bez předsudků a připustíme nejčernější scénář, dokážeme v případě nehody vrátit aplikaci do původního stavu a obnovit prostředí s dostatečnou rychlostí, ideálně okamžitě?

 

Co je základem metodiky agilního vývoje?

Při debatách o významu DevOps, o jeho fungování, principech a možnostech bychom se měli nejdříve letmo podívat na samotný agilní vývoj.

Co to je?

Existuje několik různých agilních metodik, ovšem ve své podstatě jde o rozdělení samotného vývoje do tzv. sprintů.

Sprint je předem definovaný časový úsek rozdělený na několik vývojových fází, během nichž se naplánují aktivity pro tým vývojářů. Na aktivitách se následně začne pracovat, aby se nakonec každá z nich otestovala a připravila na release, uvolnění do produkce.

 

 

Jinými slovy na konci každého sprintu je týmu Operations předána hotová funkční část aplikace, kterou tým Operations může implementovat na produkční prostředí.

 

Co tedy řeší DevOps?

Pokud se na agilní metodiku podíváme ještě jednou, tak si můžeme všimnout, že řeší pouze řízení práce vývojářů podle předem stanoveného plánu, a nikoli provozní podporu. A zde přichází na řadu DevOps, který efektivně rozšiřuje metodiku agilního vývoje o několik nových řešení.

Hlavní důraz je kladen na maximální automatizaci, díky níž lze nové řešení uvést do produkce téměř okamžitě. Lze proto říci, že v DevOps nemáme ony přesně definované časové úseky, sprinty.

Zapojením Operations do celého cyklu zároveň dostávají vývojáři zpětnou vazbu. Mohou tak již hotové řešení flexibilně opravovat, případně rozšiřovat o nové funkcionality, a reagovat tak na aktuální potřeby.

Automatizace a zapojení Operations nám přinášejí benefit v podobě stálého zlepšování dodávaného řešení (continuous improvements neboli CI).

Ovšem CI může v souvislosti s DevOps znamenat také continuous integration, kontinuální integraci. Z tohoto pohledu se od vývojářů očekává, že řešení, na kterém právě pracují, budou pomocí společného úložiště zdrojového kódu aktualizovat několikrát denně, zpravidla po dokončení každé malé funkční části, namísto sdílení hotového komplexního balíčku několika řešení.

Tato praxe umožňuje spouštět automatizované testy a snadněji provádět opravy, pokud se vyskytne chyba. Jakmile je kód otestovaný, je možné jej okamžitě, v ideálním světě DevOps opět automatizovaně, implementovat do produkce, čímž dosáhneme kontinuálního nasazení (continuous deployment – CD).

A pokud spojíme oba kroky CI a CD dohromady, získáme na první pohled dokonalý proces, tzv. CI/CD pipeline (o které už byla řeč v předchozím článku Encyklopedie).

 

 

Je to opravdu tak jednoduché?

Jednoduše řečeno: není.

Ve světě DevOps existuje nespočet nástrojů a řešení, které lze pro naše potřeby použít. Vyžaduje to poměrně komplexní analýzu požadavků a plánů do budoucna. A přesto, že je DevOps časté téma při transformaci IT prostředí do cloudu, tak samotná metodika, není jasně definovaná. Každá společnost si DevOps upravuje podle svého. Při přípravě tohoto článku jsem například narazil na rozdíly mezi českou a anglickou Wikipedií v definici jednotlivých fází.

 

 

Proč bych měl například použít nástroj, který je vytvořen v Ruby, když je moje infrastruktura postavená na Pythonu? Existují nějaké firemní předpisy, které mohou celý zamýšlený DevOps ovlivnit? Je moje prostředí založeno na cloudových technologiích, nebo lokálně instalované na servery?

Obecně je DevOps metodika spojována zejména s cloudovým prostředím. V něm je možné dynamicky spravovat celou infrastrukturu, a reagovat tak na aktuální potřeby bez nutnosti pořizovat nový hardware, což je aktivita náročná jak časově, tak finančně. Ovšem zatím ještě nežijeme na obláčku, a proto nelze při našem rozhodování vyloučit on-premise prostředí.

 

Jaké nástroje mám tedy v rámci DevOps použít?

Vhodně zvolené řešení nám může v budoucnu usnadnit přechod na nové technologie. Může nám pomoci optimalizovat chod našeho IT oddělení, možná i slučovat IT oddělení dohromady.

Jak jsem zmínil výše, tak CI/CD pipeline je vlastně několik fází, které se opakují, a pro každou fázi je vhodný jiný nástroj.

 

 

Hodí se DevOps pouze pro cloudová prostředí?

Rozhodně ne.

Postupy a nástroje doporučované pro DevOps se dají úspěšně využít pro potřeby samotných provozních týmů, které v dnešní době udržují infrastrukturu v on-premise prostředích. Jejich náplní práce je mimo jiné i řešení požadavků a problémů přicházejících od uživatelů či prostřednictvím monitorovacích nástrojů.

V takovém případě je možné považovat požadavky a problémy za jednotlivé use case pro development. Pokud jejich řešení naprogramujeme v nástroji, který nabízí centrální správu infrastruktury, například Chef či SaltStack, tak získáme opakovatelné řešení pro správu infrastruktury.

A pokud navíc připojíme zvolený nástroj přímo na zdroj požadavků a problémů, např. ServiceNow, JIRA či různé monitorovací nástroje, tak naše prostředí bude spravováno s téměř nulovou reakční dobou s minimálními manuálními zásahy.

 

Závěrem

Metodika DevOps, přestože se s ní setkáváme už od roku 2009, je mnohdy stále zahalena tajemstvím, možná i díky svobodě jejího nasazení. K důslednému pokrytí tématu DevOps by byl zapotřebí celý seriál článků (na který třeba dojde někdy v budoucnu).

Rozhodně se ovšem vyplatí se s tématem blíže seznámit na specializovaných internetových stránkách a prodiskutovat konkrétní řešení na míru s vaším cloudovým poskytovatelem.

A protože cloud není pouze DevOps, ale mnoho dalších řešení, připravujeme pro vás v ORBITu celou Encyklopedii cloudu, kde najdete další zajímavá témata.