V počátcích technologického vývoje, se projektový tým, který vytvářel aplikace, skládal z vývojářů, analytiků, testerů, systémových administrátorů, síťařů a hardwareových specialistů. Pokud byl tento tým sehraný, bylo z poloviny vyhráno. Velice zjednodušeně: Lidé zodpovědní za vývoj vytvořili aplikaci (vývojáři) a předali ji systémovým administrátorům, kteří ji nasazovali (jakkoliv automatizovaně) na hardware v serverovně.

Ne zas tak dávno přišel ke slovu tzv. agilní přístup k vývoji. Ten se tím rapidně zrychlil a komunikace mezi vývojáři a operations byla čím dál složitější. V podstatě pak stačilo málo aby produkt, (nebo jeho verze) na který klient netrpělivě čeká, nebyl vůbec doručen. Produkt, nebo jeho verze byla případně doručena, ale se značnou chybovostí. Na vině byla, a většinou stále je, komunikace mezi různými částmi týmu.

Existují tedy vývojáři a operations. Tyto dva tábory se spolu možná sice snaží komunikovat a domlouvat, ale v praxi je to velice složité. Každý mluví takříkajíc vlastním jazykem, případně jiným nářečím. To, co je jednoduché z pohledu vývoje, nemusí být implementovatelné na serverech z pohledu infrastruktury. A to, co je velice snadno řešitelné v infrastruktuře bude zase velice těžký oříšek pro vývojáře.

Co by se stalo, kdybychom měli vývojáře a poslali ho na studia k operations? Nebo z druhé strany, měli někoho z operations a poslali ho na výzvědy k vývojářům? Tímto krokem nakonec vznikne někdo, kdo si může říkat DevOps specialista. Aby si tento titul ale opravdu „zasloužil“, musí pochopit více, než z čeho projekt je a kam se implementuje. Musí změnit zejména způsob myšlení.

Mluvíme o celé sadě postupů, které automatizují a standardizují procesy mezi vývojem software a operations, tak aby bylo možné SW “buildovat, testovat a releasovat” rychleji a spolehlivěji.

You build it, you run it!

Základní myšlenkou je, že DevOps není jen technologie, ale celé paradigma vývoje. Aby to ve firmě fungovalo, je třeba změnit nejen používané aplikace, ale celý přístup k vývoji, testování i nasazování do produkce a vůbec celé uvažování nad tímto procesem.

Dříve by to byla utopie, ale dnes už je možné pronajmout a nechat si spravovat celé clustery s propojením na nejrůznější služby od databází (např. Postgres, MySQL nebo CockroachDB), přes fronty (jako Kaftka či RabbitMQ), analytické systémy (Hadoop), logovací a monitorovací infrastrukturu (Elasticsearch, kibana, grafana) až po nejrůznější IOT služby a REST API. A jak jinak urychlit celý proces od vytvoření až po nasazení aplikace, než tím, že si budete umět tyto aplikace spouštět sami.

Hybrid Cloud Architecture

Virtual Private Cloud

Pokud firma provozuje nějakou aplikaci, je dnes trendem místo vlastní on-premise infrastruktury používat cloud. Cloudová infrastruktura dnes už může být optimalizovaná pro vysokou dostupnost, pro nízkou latenci, dokonce lze nastavit, že například zákazníci z Čech budou využívat datový cloud v Německu a zákazníci z Francie ve Francii. Moderní cloudy splňují vysoké standardy zabezpečení a další výhodou je možnost používat řadu technologií spojených s jejich provozem jako službu. V reálu to znamená, že si firmy nemusejí držet specialisty, kteří se budou starat o infrastrukturu, její údržbu a instalaci, protože to vše dostanou jako službu, ve které formou tzv. microservices provozují své aplikace. Šetří se tedy (dnes tak nedostatkové) lidské síly i peníze. Důležité je vyvíjet nové aplikace jako cloud native. Nejčastější cloudy, se kterými se setkáte, jsou Azure, AWS a Google Cloud.

Internet of Things Architecture

Microservice architecture

Dříve se většina aplikací vyvíjela jako monolitická. Dnes se dělají aplikace z menších částí, které spolu přes jedno rozhraní vzájemně komunikují. Výhoda? Ty monolitické startují třeba čtvrt hodiny, menší aplikace v řádu desítek vteřin. U microservice architektury se vždy snažíme, aby byla nasazovaná jako Platform as a Service nebo Software as a Service.

Oblíbenou metodologií je v této oblasti "The Twelve-Factor App", která je vlastně souhrnem pravidel, která zásadně zpřehlední vývoj, pokud je dodržuje celý tým. Popisuje, jak zacházet s kódem, kde ukládat konfigurace, co se zálohami, buildy, jak na škálování, logy či administraci.

Caching Cluster Architecture

Serverless architecture

Další velice zajímavý stavební kámen architektury moderních aplikací je „serverless”. Z výše zmíněných malých aplikací se zkrátka vezme část kódu, která může být výpočetně náročná, nebo naopak není potřeba její neustálý běh, použije se k tomu interface, který vystavuje jak AWS (AWS Lambda) tak Azure (Azure Functions), ten si nastartuje malé subprocesy, spočítá výsledky a vrátí je zpět do servisy. Dokáže se škálovat i na úrovni funkcí, které mohou běžet paralelně a nezávisle.

Serverless Application Architecture

Automatizace

Nezmínili jsme ještě jednu vhodnou vlastnost pro DevOps a tou je lenost. DevOps si snaží maximálně ulehčit život automatizací. A automatizace je alfou a omegou dnešního DevOps vývoje. Automatizujeme nasazování, pracovní procesy, testování, infrastrukturu, i správu a revizi uživatelských práv a přístupů, prostě všechno. Kdy s automatizací začít? Pokud je potřeba jakoukoliv činnost opakovat víckrát, než jednou.

Automatizované testování kódu

Abychom mohli vyvíjet rychle a měli jistotu, že jsme nikde nic nerozbili, musíme mít vše pokryté testy, které si píší sami vývojáři. Tato myšlenka dotažena ad absurdum znamená, že by se měl naprogramovat nejdřív test a pak až funkce. Test Driven Development ostatně není v oblasti vývoje softwaru žádná novinka. Nečekat na testery a psát si testy samostatně patří to k tomu výše zmiňovanému DevOps přemýšlení.

Ve světě Javy za tímto účelem používáme JUnit, Mickito, MockMvc, Selenium, Sonar atd. Nástrojů je tedy dost, častěji chybí ochota vývojářů se touto činností zabývat.

Automatizace workflows

Pro automatizaci pracovních postupů používáme nástroje jako Jenkins (CI/CD), Gitlab, Container registry, Jira. V praxi to vypadá tak, že vývojář umístí svůj kód do GitLabu, automatická pipeline nad ním spustí unit testy, zkompiluje program a nasadí ho do prostředí na server, kde pak bude kontinuálně monitorovaný. V ideálním případě opravdu vše běží samo.

Automatizace infrastruktury: Infrastruktura jako kód!

Ideální konečný stav je, aby na všech prostředích vše běželo vždy stejně a aby se tato prostředí vytvořila na pouhé kliknutí. Nikdo tedy neinstaluje operační systém, všechno by mělo být naskriptované pomocí různých šablon. Abychom mohli vytvořit infrastrukturu jako kód, musíme nejdříve odstínit aplikaci od hardware. O to se starají například nástroje jako Docker a Podman. Vytvořenou aplikaci vezmeme a nasadíme do nějakého ekosystému – dnes nejčastěji buď Kubernetes nebo OpenShift. Všechno může běžet i on-premise, ale to není tak zásadní, oč v DevOps běží. Jak Kubernetes, tak OpenShift lze provozovat po několika kliknutích. Kubernetes běží hostovaně u všech velkých poskytovatelů (AWS EKS, Azure AKS, nebo Google GKE).

U infrastruktury máme několik možností. Můžeme „naklikat“ infrastrukturu z pohodlí webového prohlížeče, nebo, a to je více preferované, vytvořit šablonu, podle které bude poskytovatel vytvářet infrastrukturu přímo přes API vrstvu.

Nejrozšířenější univerzální šablonový software je Terraform. Obsahuje napojení na všechny velké poskytovatele, nebo je možné použít on-premise servery. Snazší a mnohdy lepší, je napsat tyto šablony v nativních scriptech (u AWS např Cloudformation v YAML a JSON, nebo nově AWS CDK, kde je možné popsat infrastrukturu např Javascriptem, v JAVA nebo Python). Tím se možnosti poskytovatele využijí na maximum. Tuto šablonu pak stačí pustit a lze s ní vytvořit identické prostředí i několikrát za sebou (vhodné pro různé environmenty dev/test) Samotné aplikace lze do prostředí dodávat pomocí všech známých nástrojů od Jenkins, Gitlab, Bitbucket.

Měření

Aplikaci máme v produkci, ale tím to nekončí. Je potřeba ji začít vyhodnocovat, analyzovat a opravovat chyby, potřebujeme tedy kontinuální metriky a nástroje pro analýzu. Ke sběru logů a jejich vizualizaci lze využít ELK Stack, což je celý balík nástrojů pro tyto účely. Kibana je nástroj, který umožňuje procházení logů ve vizualizované formě na jednom místě, což perfektně umožňuje zjistit výkon aplikace i případně odhalit, kde je přesně problém, vedle filtrování chyb lze zobrazit i metriky z CPU atd.

Metodika

Dříve tak oblíbený a často používaný vodopádový přístup sice umožňuje pečlivý, ale v žádném případě ne rychlý vývoj. Proto se dnes používají tak často skloňované agilní metodiky, které umožní rozdělit vývoj na malé části a provádět ho po kouscích. Když se nad tím zamyslíte, je to v zásadě podstata celé DevOps filozofie - od infrastruktury až po metodiku a naopak. Praktikujeme tedy denní standupy a vývoj běží v krátkých sprintech. Důležitá je standardizace celého vývojového procesu, počínaje analýzou, přes vývoj, testování, nasazování až po monitorování výkonu hotové aplikace.

Závěr

Pro úspěch DevOps projektu je potřeba kombinace odborných znalostí, kvalitní technologie, řemeslné zkušenosti, ale hlavně změna nastavení fungování týmu a uvažování vývojářů. Ale pak to stojí za to. Dobře nastavený projekt pak umožňuje rychlejší inovace, je schopen obratem reagovat na požadavky byznysu, spolupráce týmu je efektivnější, stoupá celková kvalita kódu a výsledkem jsou častější releasy.

Vojtěch Kijenský Autor článku je Solution Architect ve společnosti Cleverlance.