Prečo je potrebné zavádzať do organizácií DevOps
V 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.
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