devops je ako sex tínejdžerov. každý o tom hovorí, ale nikto nevie ako sa to má robiť, každý si myslí že to tí ostatní robia, tak mnohí tvrdia, že to tiež robia. môj vzťah k devopsu je zase ako z románu ružovej beletrie – dlho sme sa prehliadali, potom sme sa náhodne zoznámili, zahoreli sme niečím, čo som pokladal za lásku, ale skutočne som sa zaľúbil, až keď sme sa odlúčili.

trochu som zabrdol do devopsu v blogu o cloude a zmenách. písal som, že ak je vašim hlavným motivátorom pre vstup do verejného či privátneho cloudu schopnosť robiť dynamické zmeny, je nevyhnutné prispôsobiť sa organizačne. tradičné IT prostredie delí vývoj a prevádzku IT služieb na funkčné oblasti ako sú networking, prevádzka, aplikačný vývoj, či storage. typicky sú tieto role naviac organizačne delené do separátnych oddelení. toto vytvára problém, ak je potrebné danú IT službu meniť, alebo škálovať. každá zmena sa totiž väčšinou dotýka viacerých IT oddelení, pričom každé z nich môže mať svoje vlastné priority, postupy či kultúru.

koncept devops je o spojení prevádzky a vývoja do zlúčeného tímu, zodpovedného za obe tieto funkčné oblasti. vzniknutý spojený tím je následne zodpovedný za celý kolobeh vývoja a prevádzky aplikácií a veľkú časť zmenových cyklov točiacich sa okolo jednej, alebo úzkeho kruhu služieb. nespornou výhodou devops tímov, ako aj iných cross-funkčných tímov, je dynamika. zmeny sa tak môžu udiať v réžii jedného tímu.

toľko z veľkej knihy, teraz na drobné. vzorec na devops je zdanlivo jednoduchý. rovná sa dev plus ops. ale už tu robia mnohé firmy chybu: nemajú dev.

dev je vývoj, ale nie tak zase hocijaký. dev je tvorba custom aplikácií určených pre interakciu so zákazníkom. dev je schopnosť programovať unikátne a inovatívne riešenia a postupy vo vzťahu k odberateľom. tu rovnica funguje aj obrátene – nemôžete mať kompetitívnu výhodu bez dev. nemôžete byť najlepšia firma na trhu, ak budete na interakciu so zákazníkom používať štandardný komerčný škatulkový softvér.

veľa firiem by chcelo byť inovátormi, ale bez dev to proste nejde. ak si kúpite hotové riešenie od softvérovej firmy alebo systémového integrátora na kľúč, kompletne stratíte agilitu. ak budete chcieť reagovať na trhovú zmenu, alebo nebodaj vyhútať nejakú inováciu, zapadnete v blate drahých a pomalých change requestov u externého dodávateľa. kedysi stačilo meniť sa pomaly, teraz to nestačí. nedá sa byť pružný s vonkajším dodávateľom v tejto divokej, prirýchlo sa meniacej dobe. ale hlavne – nedá sa byť inovatívny na štandardnom komerčnom softvéri. veď ten si môže kúpiť aj konkurencia a budú mať to isté. ako sa potom chcete odlišovať?

každá úspešná firma sa bude musieť stať softvérovou firmou, bez ohľadu na oblasť podnikania. napríklad – tatrabanka je softvérová firma. ich softvér je jedna z najlepších a najpoužívanejších appiek v mojom telefóne. jasné, že to nie je štandardný balíkový softvér, čo si môže kúpiť každá iná banka a jasné, že im to nevyvíjal na kľúč niekto zvonka. potom by to nevyzeralo tak namakano. tatrabanka má zo päť vývojárskych oddelení, spolu s vyše sto ľuďmi, vrátane kóderov, testerov, analytikov. veľa dodatočných kóderov si bodyshopujú. povráva sa, že tú appku robia komplet interne, bol to taký test a osvedčil sa. robia agilný scrum. plánujú prejsť na devops. na budúcoročnom “IT gala” by mala táto banka súťažiť o titul IT firma roka a zvíťaziť.

(vsuvka – dnes som mal tú česť obedovať s majiteľom zabehnutej BI firmy. hundral na “spending report” v tej tatra appke, že by to mohlo byť lepšie. novinky zo sveta BI: ide to ako teplé rožky. výhľad do budúcnosti: SaaS)

(vsuvka dva: keď ešte raz na IT gala necháte vyhrať štátny projekt typu katastrálny portál, čo po spustení leakol rodné čísla a potom rachol, tak vám tam nabehne slovensko.digital s cepmi a delobuchmi)

dev nie je každý vývoj. netreba mrhať čas custom vývojom vnútropodnikových služieb, ktoré sa netýkajú customer experience (UX). robiť custom riešenia pre interné oddelenia týkajúce sa len interných procesov v súčasnosti môže byť veľmi často strata času. CIOs to poznajú – pribehne za vami nejaké interné oddelenie a bude vám tvrdiť, že majú unikátne potreby a treba im spraviť custom riešenie. obchodníci chcú voľakú špeci fičúrku na CRMku a logistika zase špeci vecičku na ich softíku a tak budete rok customizovať s externými dodávateľmi a potom to ešte dva roky integrovať s okolím. naozaj má vaše oddelenie logistiky unikátnu potrebu, ktorú nemá nikto iný na svete? blbosť. dnes už máte appku na všetko. scanner čiarových kódov na liekoch, ktorý informáciu prepojí s predpoveďou počasia a v CRM vykoná analytiku nad zákazníkmi? určite je na to appka na iphone, asi aj dve. takéto veci treba riešiť formou SaaS. vývoj sa má týkať customer-facing vecí.

sú oblasti, kde sa stali produkty úplnou štandardnou komoditou, takže jednotliví dodávatelia môžu súťažiť len v oblasti UX. dá sa možno argumentovať, že schopnosť bánk ochrániť vaše peniaze a bankové produkty sú viac menej identické, rozdieľ medzi bankami je preto potom možno práve v UX, tatra to asi chápe. telefonovanie z O2 je asi to isté ako z Telekomu, a iphone od jedného aj druhého vyzerá rovnako, takže rozdiel by sa mali snažiť budovať v tom, akým spôsobom ten iphone dodajú a aké služby, informačné, analytické, spotrebné, lokalizačné atď. mi k tomu dodajú. je to aj o tom, kto z nich presnejšie vycíti moje potreby a ponúkne mi niečo, čo naozaj potrebujem. rozdiel je v UX.

aký má mať zákazník zážitok, keď si niečo kupuje? taký, ako keď si kupujem knižku v martinuse. vyklikám si to v pohľadnom online obchode, pred zaplatením sa mi doporučia ďaľšie produkty na základe mojich potrieb a správania. potom online sledujem dodanie tovaru, po dodávke dostanem dotazník spokojnosti a keď v ňom trochu zahundrem, hneď sa mi niekto ozve. keď mám meniny, dostanem pekný mail a malý darček.

zažil som, keď má firma vlastný vývoj front-end vecí a je to mega. websupport napríklad zažíval dlho úplne fenomenálny rast a väčšina sa z toho dá pripísať asi kvalitnej podpore, ale veľa aj custom vývoju. ak by mali na správu webhostingu kúpený cPanel (štandardný komerčný balík na správu webov), ako všetci ostatní, v čom by sa odlišovali a prečo by k nim ľudia vo veľkom prechádzali?

tip na UX firmu – 2fresh. koniec reklamy. tinu poznám.

dev by sme mali, teraz ops. (sorry trvá to, ale dostaneme sa aj k devops a cloudu).

prevádzkari zažívajú trochu krízu, sa mi zdá. kedysi mali pokoj, teraz sa všetko mení, zmeny im prinášajú robotu a problémy, tak rezistujú, čo sa dá. tvrdia, že zmeny prinášajú výpadky, to je pravda, ale nechápu, že niekedy sú zase výpadky kvôli tomu, že sa nespravila zmena, ako žiadaná reakcia na niečo externé. IT operations je dôležitá, príťažlivá a zodpovedná práca. ale v súčasnej dobe vo veľa firmách pôsobia ako ručná brzda.

presunom ops do devops sa stanú prevádzkari vnímavými na to, o čom tá služba, ktorú prevádzkujú, vlastne je. budú prežívať radosti a starosti daného produktu. budú sa tešiť, že sa tá služba predáva, a budú tŕpnuť, keď sa bude robiť prieskum spokojnosti zákazníkov. v cross-funkčnom tíme zameranom na službu získajú prevádzkari (aj vývojári) vnímavosť produktového manažéra.

devops je o zmene kultúry a o zmene myslenia. celý devops koncept sa dá implementovať nielen vo veľkom tíme, ale aj v jednej hlave. minule mi na tému devops nechápavo krútil hlavou jeden prevádzkar, že veď on nevie programovať, tak nemôže byť devops. môže. každý prevádzkar vie základy programovania, alebo aspoň scriptovania a na tom sa dá ďalej stavať. ak sa napríklad rieši prevádzkový problém nejakou zmenou, on vie najlepšie o čom ten problém je, on je motivovaný ho vyriešiť, lebo jeho páli. možno nevie nakódiť riešenie, ale môže sa hodiť napríklad ako projektový manažér tej zmeny. viete si predstaviť zanietenejšieho projektového manažéra, ako toho, čo práve dostal tím vývojárov, aby vyriešili jeho prevádzkový problém? každý z nás miluje hovoriť o svojich problémoch a riešiť ich. cudzie problémy nás nudia.

možno úplne najväčší prínos devopsu je preto práve v motivácii. zaujímavý príklad cross-funkčného tímu na ktorom to demonštrujem, sú americké vojenské jednotky. tie majú 5 až 12 vojakov a skrývajú v sebe všetky funkcie: veliteľ, navigátor, nabíjači, komunikátor, medik, atď. predstavte si teraz, aké by to bolo, keby nemali vlastného medika. zriadilo by sa na základni jedno centralizované oddelenie medikov a tam by sa nosili všetci, aj mierne ranení vojaci. navigátor by si v boji zlomil ruku a vy by ste ho museli doniesť na oddelenie medikov. oddelenie medikov by časom pochytilo vlastnú kultúru. o vojakoch ako vy by si mysleli svoje. vášmu ranenému by pridelili prioritu podľa svojho uváženia. pche, zlomená ruka? my tu riešime seriózne operácie, tak počkajte v rade. takto vznikol a funguje IT operations. ak ale máte svojho vlastného medika, pozná vás. viete čím žijete, o čo vám ide, čo máte radi, koľko máte detí. ak si zlomíte ruku, okamžite na bojisku s nasadením života a slzou v oku vás s láskou ošetrí. to je ten rozdiel v devops.

devops je aj o zvedavosti. je to o tom, že ľudia sa chcú učiť, posúvať. mám dojem, že sa to vytráca. ja som možno ešte z tej generácie, čo sa nevedela dostať k informáciám a možno práve preto sme po nich prahli. pripomína mi to teóriu, podľa ktorej ak by marihuanu legalizovali, všetci by sa na ňu vykašľali a našli by si niečo iné zakázané. začiatkom deväťdesiatych rokov sme robili trashdiving, hrabali sme sa po kontajneroch slovenských telekomunikácií, hľadajúc manuály k HP-UX! mali pre nás cenu zlata. teraz sa dajú voľne stiahnuť a ľudia sú leniví si niečo prečítať. ale nie všetci. aj v tých najnudnejších korporáciách som počas kariéry našiel hustých nadšencov, čo sa radi vo všetkom vŕtajú a nadšene sa učia. takých si nájdite na devops, nie zabednených hundrošov.

devops by sme mali, teraz devops_support. áno, dá sa to celé rozšíriť napríklad aj o L2 podporu a dáva to úplný zmysel. príchodzie tickety treba klasifikovať, grupovať a analyzovať a opakované problémy vykoreňovať. ak dáte šikovnému L2 technikovi pár dní voľno od hotline a pridáte k nemu nejakého vývojára, dokážu vyriešiť opakujúci sa problém. a hľa, klesne počet ticketov, stúpne spokojnosť zákazníkov. sú oddelenia, ktoré asi nikdy nebude dávať zmysel rozpustiť do tímov okolo služieb, trebárs security alebo networking. viem si ale predstaviť úlet – rozpustiť časť HR a poslať jednu HRistku do každého väčšieho tímu.

príklad z praxe: v menšej firme som zažil rastúce vývojové oddelenie. postupne sa tam vytvorila vlastná kultúra, chodili spolu do krčmy a o zvyšku firmy si mysleli svoje. marketing mal vždy dojem, že vývojári nestíhajú, lebo furt makajú pre prevádzku. prevádzkari mali dojem, že im furt nestíhajú na vývoji porobiť veci, lebo makajú pre marketing. keď si marketing aj prevádzka začali hľadať externých dodávateľov na vývoj, tento interný dev ani brvou nepohol a žil si ďalej svojím vlastným životom. ale majiteľ firmy si to uvedomil a spravil radikálny rez. oddelenie vývoja zrušil a vývojárov rozpustil po jednom do každého oddelenia. zafungovalo.

rozhodenie špecialistov z jednej oblasti medzi tímy môže mať aj nevýhody napr. zníži sa ich utilizácia. lebo ak dáte ku každej službe rovnaký počet vývojárov, niektorí sa môžu nudiť a iní prepracovať. celý nápad môže byť ohrozený, ak líder cross-funkčného tímu sám nie je všestranný ako šviajčiarsky nožík. ale aj tak – zdá sa, že táto doba dáva na najvyšší piedestál agilitu.

ok, konečne na ten cloud!

všetko je o službách. fyzické produkty akoby zanikajú, stávajú sa z nich len nosiče služieb. autá v amerike sa menia z kusov kovu a plastu na prijímače navigačných, asistenčných a streamovacích služieb. je pravdepodobné, že sa raz budú predávať autá ako telefóny. čiže kúpim si dotované auto s viazanosťou a budem platiť mesačne za rôzne služby. mobil za korunu? auto za korunu. rovnako taký iphone nie je kus kovu a skla, ale platforma na dodávku najrôznejśích služieb. tatrabanka nie je len fyzický trezor s vašimi peniazmi, je to aj provider analytických služieb. časom im možno budete platiť viacej za analýzy “spending reportu”, ako za prevodné príkazy.

premena produktov na služby sa týka aj hardvéru a softvéru. volá sa to, ehm, cloud. hardvér ako služba rovná sa IaaS. obdobne je to so softom. kedysi robili softvérové firmy softvérové produkty a dodávali ich prostredníctvom resellerov a implementátorov zákazníkom, ktorí si ich prevádzkovali. dnes to tie softvérové firmy budú samé prevádzkovať zákazníkovi a dodávať mu to ako službu.

je tu aj snaha etablovať firmy, ktoré budú stáť medzi SaaS providerom a zákazníkom. toto vlastne tvorí časť mojej súčasnej práce. verím v to. predstava je, že ten prostredník zastreší priamy predaj cez sieť obchodníkov, online nákup “pod jednou strechou” viacerých appiek, porieši billing a L1 support.

ešte bleskovo o tej zmienke z úvodu, že ako som sa dostal k devopsu. s nápadom prišiel kolega a kamarát. nechápal som, neveril som, teraz som zarytý devopista. ľudia si často osvoja veci a zabudnú, alebo nepriznajú pôvodcu idey. všetko máme od niekoho. ďakujem véčko.

ak niekto z vás robí niečo zaujímavé s devopsom, alebo s cloudom, zavolajte ma na pivo pokecať. pijem biele víno. rád sa niečo naučím a vymením nápady.

záverom len odvekú múdrosť, že sa treba stále vzdelávať. ak stále žijete v klasickom IT svete, kde sa dodáva hw a na ňom sa implementuje soft, ok, ešte chvíľu vám to pofrčí, ale vyhraďte si peniaze a čas a hrajte sa s novými formami cloudových modelov. učte sa byť agilní. musíte ísť do cloudu a musíte robiť devops.

môžem ja už skončiť bez fotky cloudu? mam ich ozaj dosť: