Viime vuosina on puhuttu paljon DevOpsista ja sitä on pidetty lähestymisenä, joka ratkaisee kaikki perinteisen IT:n ongelmat.
Tässä kirjoituksessa käsittelen syitä, miksi DevOps ei ehkä olekaan se oikea ratkaisu monellekaan yritykselle.
Kun olet lukenut kirjoituksen, tiedät mm.
* Miksi DevOpsin toteuttaminen on vaikeaa
* Mitä ongelmia DevOpsiin liittyy
Aloitetaan kuitenkin siitä, mistä DevOpsissa on kyse.
Mistä DevOpsissa on kyse?
Jotta olisi helpompi ymmärtää, mistä DevOpsissa on kyse, on hyvä muistella, millainen oli perinteinen IT-organisaatio ennen DevOpsia.
Perinteisesti ohjelmistokehitys eli Dev on ollut oma organisaationsa ja IT-infran ylläpitoporukka eli Ops on ollut oma porukkansa. Kun softakehitys eli Dev on halunnut saada uuden version ohjelmasta tuotantoon, on se antanut asennuspaketit ylläpitoporukalle eli Opsille ja sitten Ops on vienyt uuden softan tuotantoon.
Koska nämä kaksi erilaista tiimiä ovat olleet henkisesti aika kaukana toisistaan, on ohjelmistojen vieminen tuotantoon ja ylläpito ollut hidasta ja hankalaa. Jotta tämä ongelma saataisiin ratkaisua, on kehitetty DevOps.
Mitä DevOps siis on?
DevOps on tapa organisoitua
DevOps on toimintamalli, joka yhdistää ohjelmistokehityksen (Dev) ja It-infran ylläpidon (Ops). DevOps perustuu siis ajatukseen, että Dev ja Ops muodostavat yhden tiimin eli DevOpsin. Samassa tiimissä on siis sekä devaajia että IT-infran osaajia.
Yksi DevOpsin perusajatuksista on, että kun yksi tiimi osaa sekä koodauksen että koodin viemisen tuotantoon ja tuotannon ylläpidon, häviää tiimien välinen kuilu. Koska koodin vieminen tuotantoon on nyt yhteisen tiimin ansiosta helpompaa, voidaan koodia viedä tuotantoon useammin ja saada näin nopeutettua sykliä, jolla ohjelmistopäivityksiä tehdään.
DevOps on myös automaatiota
DevOpsissa ei ole pelkästään kyse organisoitumisesta. Kyse on myös automaation hyödyntämisestä. Koska DevOpsin perimmäinen tavoite on lyhentää järjestelmän kehityssykliä, pyritään DevOpsissa hyödyntämään automaatiota mahdollisimman paljon.
DevOps perustuukin automaatioon, jatkuvaan uuden koodin integroimiseen olemassa olevaan koodiin ja jatkuvaan tuotantoon viemiseen. Näin DevOps-tiimit voivat reagoida nopeammin markkinoiden tarpeisiin ja korjata ongelmia lähes reaaliajassa.
Nopea kehityssykli mahdollistaa kokeilevan kulttuurin
Koska DevOps-kulttuuri nopeuttaa ongelmiin reagoimista, mahdollistaa se kokeilevan kulttuurin. Koska virheiden korjaaminen on DevOpsissa helpompaa kuin perinteisessä hitaammassa mallissa, rohkaisee DevOps-kulttuuri kokeilemiseen ja oppimiseen.
Ympäristö, joka sallii virheiden tekemisen, edistää innovointia, koska virheistä voidaan oppia ilman suurta riskiä. Tämä puolestaan auttaa vastaamaan asiakkaiden tarpeisiin nopeasti.
DevOps kannustaa tekemään helposti ylläpidettävän järjestelmän
Yksi DevOpsin perusajatuksista on "You build it, you run it". Sen voisi sanoa suomeksi vaikkapa näin: "Te rakensitte tämän, joten saatte myös ylläpitää sitä."
"Te rakensitte tämän, joten saatte myös ylläpitää sitä."
Toisin sanoen, ideaalitilanteessa DevOps-tiimi vastaa sekä ohjelmiston rakentamisesta että tuotantoon viemisestä, mutta myös tuotantoympäristön ylläpidosta.
Tätä samaa logiikkaa on käytetty myös esimerkiksi rakentamisessa. Siellä puhutaan elinkaarihankkeista. Sama toimija rakentaa esimerkiksi kiinteistön ja vastaa myös sen kunnossapidosta. Tämän ajatellaan kannustavan laadukkaaseen tekemiseen, koska rakennusvaiheen ongelmat tulevat selkeämmin vastaan kunnossapidossa.
Kuulostaa selkeästi siltä, että DevOp on täydellinen ratkaisu ohjelmistokehityksen ja IT-infran ylläpidon ongelmiin. Joillekin organisaatioille se sopiikin erittäin hyvin. Toisille taas huonosti.
Mistä oikein on kyse? Jatka lukemista, niin saat tietää.
Mitä ongelmia DevOpsiin liittyy?
Käydään nyt kuusi DevOpsiin liittyvää ongelmaa. Kun olet lukenut nämä, ymmärrät, miksi DevOps ei todellakaan ole hyvä ratkaisu monellekaan tavalliselle organisaatiolle.
1. DevOpsin toteuttaminen vaatii paljon osaamista
DevOpsin toteuttaminen vaatii paljon osaamista. Siksi se sopii sellaisille organisaatioille, jotka ovat pystyneet houkuttelemaan paljon osaavaa henkilökuntaa.
Tällaisia yrityksiä ovat esimerkiksi digiajan menestyjät, kuten Amazon, Google, Netflix jne. Näillä firmoilla on iso vetovoima ja kyky rekrytoida markkinoilta parhaita osaajia. Tällä on merkitystä, koska DevOpsin toteuttaminen on teknisesti hyvin vaativaa.
Aika monessa tavallisessa yrityksessä asiantuntijatiimien taso ei ole riittävä puhdasoppisen DevOpsin toteuttamiseen. Tässä piilee DevOpsin heikkous monen ns. tavallisen firman kannalta.
Ilman riittävää osaamista, DevOps jää tyngäksi ja aiheuttaa enemmän ongelmia kuin hyötyjä.
2. DevOpsin vaatima kulttuurimuutos on vaikea toteuttaa
DevOps vaatii teknologiatiimeissä isoa kulttuurimuutosta. Koska perinteisesti ohjelmistokehitys ja ylläpito toimivat erillään omissa siiloissaan, tiimien sekoittaminen ja saaminen toimimaan yhdessä on vaikeaa.
Usein DevOps-toimintaa ei saada kattamaan koko organisaatiota, vaan se jää eri asteisiksi kokeiluiksi, jotka eivät tuota riittävää muutosta organisaation toimintaan.
Kannattaa tutustua Mathhew Skeltonin ja Manuel Paisin DevOps-organisaatioita käsittelevään artikkeliin DevOps anti-types.
3. Kehittäjien käyttäminen koko ympäristön ylläpitoon on kyseenalainen ratkaisu
Se, että kehitystiimi ottaa vastatakseen jonkin ympäristön ylläpidon, vaatii isoa muutosta kulttuurissa. Käytännössä tämä kohtaa herkästi vastustusta, koska tiimin ajasta pitäisi allokoida osuus vanhan ympäristön ylläpitoon.
Ensinnäkin tämä vähentää aikaa, jonka ohjelmistokehitystiimi voi käyttää uuden rakentamiseen. Toiseksi tämä kaatuu herkästi osaavimpien yksilöiden työksi ja se pirstaloi entisestään näiden yleensä kaikkein tuottavimpien asiantuntijoiden ajankäyttöä.
Jos siis ajattelee DevOps-kulttuurin omaksumista omassa organisaatiossa, joutuu miettimään, onko järkevää kuormittaa kehitystiimejä ylläpitotöillä.
4. DevOps-työkalujen ja prosessien kehittäminen ei onnistu keneltä tahansa
DevOps perustuu vahvasti automaatioon ja kehittyneiden työkalujen hyödyntämiseen uuden koodin integroinnissa vanhaan, testauksessa ja tuotantoon siirrossa.
Tämän CI/CD-putken (Continuous Integration / Continuous Delivery) rakentaminen vaatii paljon työkalujen virittelyä ja siten paljon osaamista. Käytännössä homma kaatuu kehitystiimien kokeneimmille asiantuntijoille.
Kannattaako kokeneimpien kehittäjien aikaa käyttää ympäristön rakentamiseen tiimin muille kehittäjille? Sitä jokainen joutuu miettimään.
5. Monta DevOps-tiimiä johtaa moneen erilaiseen ympäristöön
Koska DevOpsin perusidea on, että tiimit rakentavat työkalupuolta itse, johtaa tämä isommassa organisaatiossa siihen, että joka tiimillä on erilaiset prosessit ja erilainen työkalusetti. Tämä johtaa helposti kaaokseen ja kustannusten kasvamiseen, koska jokainen työkalu maksaa jotain, jokainen tiimi käyttää aikaa työkalujen virittämiseen ja ympäristön ylläpitoon.
Kun kaikki kehitystiimit joutuvat rakentamaan oman infran, ajoympäristöt, CI/CD-putket, rakentamaan valvontajärjestelmät ja huolehtimaan kokonaisuuden tietoturvasta, vie se paljon resursseja.
Organisaatio, joka toteuttaa DevOpsia orjallisesti, ajautuu vaatimustenmukaisuuden ja auditoinnin kannalta hyvin haastavaan tilanteeseen, koska vaatimusten mukaisuuden varmistaminen vie erilaisissa ympäristöissä moninkertaisesti aikaa verrattuna yksinkertaisempaan lähestymiseen.
6. Devops voi johtaa tietoturvakatastrofiin
Jos yksittäiset tiimit ovat vastuussa koko ympäristöstä tietoturvaa myöten, voi arvata, että yksi tiimi ei yksinkertaisesti pysty huomioimaan ihan kaikkea, mitä pitäisi.
Tämä johtaa helposti puutteelliseen tietoturvaan IT-infran, sovelluksen tai CI/CD-putken osalta. Tätä on lähdetty korjaamaan erilaisilla DevOps-muunnelmilla, kuten DevSecOps, joiden perusajatus on, että tiimin pitää huolehtia ohjelmistokehityksen ja IT-infran lisäksi myös tietoturvasta.
Koska tietoturvan sisäänrakentaminen ohjelmistoihin ja IT-infraan on haastavaa kenelle tahansa, tähänkin joudutaan käyttämään tiimien kokeneimpia jäseniä, josta seuraa samat ongelmat kuin aiemmin kuvasin.
Yhteenveto
Devops on hienon kuuloinen juttu, mutta sen käytännön toteutus on haastavaa. Se vaatii niin paljon osaamista, että siihen joudutaan käytännössä kiinnittämään tiimien osaavimpia yksilöitä.
Ei tarvitse olla Einstein, että ymmärtäisi, että tästä seuraa ongelmia. Koska softakehityksessä on yksilöiden välillä muutenkin todella isoja tuottavuuseroja, tämä nipistää osaavimpien kehittäjien tuotosta, kun he ajautuvat tukitöihin, jotta muu tiimi pystyy toimimaan.
Samoin se, että yhdessä yrityksessä tehdään samaa asiaa monin erilaisin työkaluin ja prosessein, on tietysti aika typerää eikä kukaan halua sitä.
Mitä sitten tuoda DevOpsin tilalle? Tuntuisi siltä, että DevOpsissa on niin paljon hyvää, ettei sitä kannataa heittää kaivoon ihan kokonaan.
Käsittelen seuraavassa kirjoituksessa seuraavaa askelta, minkä moni firma on ottanut. Se on DevOps-kentän kuuma puheenaihe juuri nyt.
Kannattaa tilata uutiskirje, niin saat tietää, kun julkaisen seuraavan kirjoituksen.