fb
IT Systems 12/2019 Projektové řízení ITIL – Řízení IT 23. 1. 2020 7:00

Prečo je potrebné zavádzať do organizácií DevOps

Je DevOps technologický upgrade alebo transformačný projekt?

UnicornV súčasnosti vzniká tradičným firmám konkurencia v podobe mladých dravých firiem, ktoré dokážu lepším využitím technológií podstatne rýchlejšie reagovať na potreby trhu.

Tradičné firmy majú základy svojich IT oddelení v období 80. až 90. rokov, silne procesne orientované a často v podobe dedikovaných tímov pre jednotlivé IT zdroje, ako sú storage, networking, security, infraštruktúra a podobne. Používatelia, ktorí potrebujú tieto zdroje, požiadajú o ne pomocou tiketov, ktoré na druhej strane spracuje člen tímu a túto žiadosť vybaví. Toto tiketové manažovanie zdrojov trpí mnohými neduhmi. Na druhej strane je človek, ktorý môže požiadavku pochopiť nesprávne, nedodať v požadovanej kvalite alebo zaniesť ľudskú chybu napríklad v podobe preklepu.

Spracovanie komplexnejších požiadaviek pozostávajúcich z kombinácie týchto zdrojov násobí tieto problémy na vyššej úrovni – jednotlivé tímy majú rôzne priority, motivácie a disciplínu. Vybavenie komplexnejšej požiadavky trvá nesmierne dlho. Náročnosť získať zdroje na svoj projekt vytvára predpoklady na vytvorenie „sivej“ infraštruktúry, napríklad server pohodený kdesi v kancelárii s nainštalovaným posledným Dockerom a podobne, pretože je to „rýchlejšie“.

Paralelne vzniká aj potreba akýchsi vybavovačov, ktorých úlohou je tlačiť na to, aby tikety boli riešené, často osobnou návštevou a doslova státím nad človekom, kým nevybaví požiadavku. To vedie k strate motivácie ľudí v tímoch. Celé dni riešia len požiadavky používateľov, a teda akúsi operatívu, často za nimi niekto chodí, s tým že potrebujú práve „toto“ a práve „teraz“. Je teda ľahké pracovať veľa, ale bez toho, aby sa podstata veci významnejšie vyriešila systémovo.

Dôsledkom je, že robiť zmeny alebo nasadzovať nové prostredia, v ktorých budú fungovať nové aplikácie, môže trvať týždne až mesiace. To je veľký rozdiel oproti hypotetickému fintech startupu z Ázie, ktorý môže nasadzovať svoju aplikáciu 2× denne bez narušenia chodu služby, a tým rýchlejšie konvergovať k požadovanej funkcionalite.

Samotný DevOps je však len vyvrcholenie „agilizácie“ organizácie a snaha prevádzkovať ho v klasickom korporátnom prostredí je odsúdená na neúspech, pretože transakčné náklady na získanie IT zdroja sú vysoké.

Prínosy moderného DevOps

Pojem DevOps býva často zneužívaný len ako trendové pomenovanie starého administrátorského tímu. Koncept DevOps vznikol z potreby rýchlej reakcie na prudko sa meniacu situáciu v mladých internetových startupoch.

Jeho začiatky siahajú do spoločností typu Facebook, respektíve Google, ktoré rástli extrémne rýchlo – denne im pribudlo milión nových používateľov, ktorí chceli službu využívať, čo vytváralo obrovský tlak na rýchly sled zmien. Technológie a procesy, ktoré fungovali pri menšom počte používateľov, rýchlo prestávajú fungovať a musia sa obmieňať. Preto prevádzka počas takéhoto rastu vyzerá skôr ako výmena motora a kolies na aute počas plnej rýchlosti na diaľnici bez prerušenia chodu.

Spojenie DevOps, čiže Developer a Operations, vzniklo ako snaha skrátiť spätnú väzbu na dianie v prevádzke rapídnym vývojom a nasadzovaním. DevOps taktiež rieši problém vo vzťahu administrátor – vývojár, pretože táto separácia núti prevádzkovať administrátorov aplikáciu, ktorú nevyvinuli, zatiaľ čo vývojári nepíšu kód s ohľadom na prevádzkovateľnosť („na localhoste mi to funguje“).

DevOps je teda o vertikálnej integrácii, pri ktorej vývojár vytvorí novú produktovú vlastnosť od frontendu až po backend, od jej naprogramovania po nasadenie a monitoring. Keďže vývojár je zodpovedný aj za prevádzku, je predpoklad, že kód bude napísaný kvalitnejšie.

Dôsledkom tejto vertikálnej integrácie je aj zastupiteľnosť – ak sa v tíme používajú spoločné nástroje, nemal by byť problém nahradiť vývojára niekým iným, pretože všetky procesy a nástroje zostávajú rovnaké. V korporátnom prostredí je však bežnejšie, že kombinácia rolí Dev a Ops sa deje na úrovni tímu, čo môže byť vhodný kompromis s dostatočným efektom.

Ako zaviesť do organizácie moderné DevOps?

Moderné DevOps si vyžaduje na svoje fungovanie agilnú IT infraštruktúru. To sa najlepšie dosahuje v cloude, či už v privátnom (Openstack), alebo verejnom (AWS, GCE). Spoločným znakom je však instantná dostupnosť IT zdrojov, o ktoré vývojár požiada cez štandardizované rozhranie API alebo webové rozhranie.

Korporátne organizácie majú občas potrebu riešiť problém tiketového spôsobu vytvárania IT zdrojov vývojom vlastného systému na vytváranie virtuálnych serverov, alokáciu IP adries alebo vytvorenie DNS záznamov. Aj keď to môže mať krátkodobý efekt, je to nesprávny krok, ktorý sa vypomstí neskôr – ľudia zodpovední za vývoj odídu a o systém sa nemá kto starať. Komplexnosť tejto úlohy veľmi rýchlo narastá a presiahne možnosti jeho vývojárov. Preto je vždy lepšie investovať čas a energiu do integrácie existujúceho systému, ako sa o to pokúsiť sám.

Predpoklady

Zavedenie moderného DevOps vyžaduje splnenie určitých predpokladov:

  • Kvalitný a skúsený realizačný tím
  • Podpora manažmentu a zadefinovaný sponzor projektu
  • Podpora end-to-end zmien (technologických, procesných a organizačných)
  • Vytvorenie tlaku na ostatné organizačné jednotky v IT – všetci musia prijať nový koncept za svoj a podporovať ho

Technologický upgrade

Väčšina korporácií prevádzkuje tradičné hardvérové a softvérové stacky. Moderné IT však menia prístup k hardvéru a inklinujú k presunu mnohých funkcií do softvéru. Z hardvéru sa tak stáva lacná komodita a mení sa aj spôsob obstarávania a špecifikácie hardvéru. Často je možné ušetriť aj 30 – 50 % v porovnaní s tradičnou infraštruktúrou.

Funkcie biznis kontinuity ako vysoká dostupnosť, load balancing či dynamické škálovanie sa presúvajú do softvérovej platformy, respektíve samotnej aplikácie. Je lacnejšie a často aj jednoduchšie zabezpečiť tieto funkcie priamo v aplikácii, pričom tieto funkcie tiež fungujú lepšie a spoľahlivejšie, než to býva na úrovni infraštruktúry. Je to z jednoduchého a logického dôvodu – aplikácie si ľahšie postrážia konzistenciu dát a transakcií, než to býva na úrovni infraštruktúry, ktorá o aplikáciách „nevie“.

Transformačný projekt

Zmeny v procesoch, aplikáciách aj správe infraštruktúry a platforiem celkovo znamenajú komplexný transformačný projekt, kde sa postupne menia celé IT. Tieto zmeny je nutné primerane riadiť a správne implementovať.

Transformácia sa vždy realizuje paralelne k fungovaniu tradičného IT modelu a s postupnou migráciou aplikácií zo starého modelu do nového a vo veľkých organizáciách obvykle trvá 1 – 2 roky. Výsledkom transformácie je efektívnejšia IT organizácia, agilnejšie dodávky aplikácií, pružnejšie a nákladovo efektívnejšie fungovanie IT.

Skúsenosti z reálneho projektu – Openstack Pilot

Openstack Pilot bol projekt, ktorý mal za úlohu ukázať pozitívne vlastnosti privátneho cloudu. Rozdiel v rôznom prístupe k manažmentu IT zdrojov je možné vidieť v tabuľke:

Task Time to complete
Preparation of physical infrastructure 129 600 minutes (3 months)
MaaS.io deployment 15 minutes
Deployment of Physical nodes with MaaS.io 10 minutes
Deployment of OpenStack and Ceph 120 minutes
Deployment of k8s cluster 25 minutes

Zatiaľ čo príprava samotného prostredia pre Openstack trvala 3 mesiace, pretože sa niesla v duchu tiketového alokovania IT zdrojov, po automatizovanej inštalácii serverov MaaS (maas.io), Openstacku a Kubernetesu je vidieť dramatický rozdiel v čase v prospech týchto nástrojov.

Úlohou MaaS je manažovať životný cyklus serverov. Po ich automatizovanej registrácii (cez PXE network boot) ich získava pod kontrolu a je možné nainštalovať operačný systém požadovaného typu.

Po automatizovanej inštalácii OS máme vytvorený tzv. undercloud, ide teda o prostredie, kde majú servery priradené IP adresy, fungujúce DNS a integráciu s Ansiblom, ktorý môže ťahať dáta o serveroch priamo z MaaSu. Trvalo to asi 15 minút a približne tri kliknutia myšou.

Toto prostredie je vhodné na nasadenie Openstacku, čo je orchestrátor IT zdrojov v sieti (podobne ako MaaS), ale na vyššej úrovni a škále. Zatiaľ čo príprava samotného prostredia pre Openstack trvala 3 mesiace, pretože sa niesla v duchu tiketového alokovania IT zdrojov, po automatizovanej inštalácii serverov MaaS (maas.io), Openstacku a Kubernetesu je vidieť dramatický rozdiel v čase v prospech týchto nástrojov.

Peter Brtáň Peter Brtáň
Autor článku Peter Brtáň riadi v Unicorn Systems SK realizačnú divíziu zameranú na finančnú oblasť (Home Credit, Ferratum Group, Tatra banka, ČSOB, Slovenská Sporiteľňa...). Pre Unicorn Systems pracuje od roku 2011.
Tomáš Čorej Tomáš Čorej
Druhý autor Tomáš Čorej pôsobí v Unicorne ako konzultant pre open-source cloudové technológie využívajúce komoditný hardvér na škále a automatizovane. Tento prístup sa snaží presadzovať aj v korporátnom (najmä finančnom) sektore s cieľom znižovať náklady na IT.

Kalendář akcí
Konference - Semináře - Školení
Časopis IT Systems/Speciál
Aktuální číslo časopisu IT Systems Aktuální číslo časopisu příloha #1
Archív časopisu IT Systems
IT Systems 4 IT Systems 3 IT Systems 1-2 IT Systems 12
Archív časopisu IT Systems Special
Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1 Aktuální číslo časopisu příloha #1