IT-spetsialistide hulgast kostab viimasel ajal üha sagedamini arutlusi GitOpsi ning DevOpsi teemadel. GitOpsi on endiselt n-ö haibi faasis, kuid selle potentsiaal ning positiivne mõju võivad osutuda väga suureks.
GitOpsi juurutamine on täie hooga käimas Siseministeeriumi infotehnoloogia- ja arenduskeskuses (SMIT). Kas GitOps täiendab DevOpsi loodetult? Kas infrastruktuur-kui-kood kasutamine aitab saavutada sujuvama ja kiirema tarkvara arendamise? Nende küsimuste üle arutleb TalTechi IT süsteemide administreerimise õppekava programmijuht ning SMIT-i baasteenuste valdkonna arhitekt Siim Vene.
Klassikaliselt on vajalikud infraressursid pidev konfliktide allikas
Siim Vene nendib, et rakenduste tööks vajalike teenuste tellimine (näiteks virtuaalserverid, tulemüürireeglid, koormusjaoturite seaded) on ettevõtetes arendajate ja IT-osakonna vaheline tüüpiliselt aeganõudev tegevus, mis põhjustab sageli vastasseise. Halvemal juhul võib arendajatel kuluda päevi või koguni nädalaid selleks, et saada oma tööga edasi minna või vajalik ärirakendus tööle panna.
GitOpsi näol on tegemist uudse lähenemisega sellele, kuidas infosüsteeme on võimalik tarnida ja ka hallata. Raamistik üritab neid kitsaskohti lahendada sellega, et rakenduse tööks vajalikku taristut või platvormiteenuse ressurssi kirjeldatakse deklaratiivselt arendajate poolt “konfiguratsioon-kui-kood” abil, tarnitakse automaatselt ja iseteeninduslikult ning see tähendab, et teiste osakondade spetsialistide taga ei pea arendajad enam nii palju ootama või erinevate protsesside keerukusest sõltuma.
GitOpsi kontseptsioon tugineb väga suures osas tarkvaraarenduse põhimõtetel ja see tagab, et meeskonnad, kes oma töös kasutavad kaasaegseid tarkvaraarenduse tööriistu, saavad neid hõlpsasti kasutusele võtta. Teisalt on muutused siiski üsna suured ja põhimõttelised.
Kui varem oli nii arendajatel kui ka süsteemiadministraatoritel teadmine peamiselt oma domeeni spetsiifikast, siis nüüd peavad nad olema võimelised vastastikku rohkem teadmisi omandama hakkama.
Muutused on suured
Vene nendib, et pea kõik eluvaldkonnad on mingitpidi seotud infotehnoloogiaga. Infotehnoloogia omakorda aga on praegu hästi kiires muutumises. Ettevõtted ja organisatsioonid püüavad sellega sammu hoida ning muutused toimuvad ka IT-ga seotud spetsialistide töös.
Viimaste aastate suurim “maalihe” on Vene sõnul see, et kui klassikaliselt on IT-administraatorid hallanud süsteeme üsna kitsalt ja tihtipeale süsteemispetsiifiliste tööriistadega, siis praegused trendid sunnivad kasutama üha rohkem arendajate tööriistakohvris sisalduvat, nagu näiteks tarkvara koodihoidlad või koodi tarnimise tööriistad. Seda trendi on peamiselt suunanud aina kasvav süsteemide omavaheline integratsioon ning platvormiteenuste iseteenindsliku rõhuasetusega disain.
“On paratamatus, et juba lähiaastail hakkab süsteemide administreerimine aina rohkem sarnanema teenuste arendamisega, mis toob kaasa väiksema vajaduse administraatori profiiliga spetsialistide järele, kes ei suuda muudatusega kaasa tulla ning arenduse tööpõhimõtteid endale selgeks teha,” nendib Vene.
Muutused nagu öeldud, on suured, kuid näiteks küsimust teemal DevOps vs GitOps nimetab Vene siiski pigem ühe mündi eri poolteks. “Need ei ole otseselt vastanduvad kontseptsioonid, ühte võib pidada rohkem filosoofiaks ning teist selle filosoofia rakendamise meetodiks,” kinnitab DevOpsi juurutamise kohta magistritöö kaitsnud Vene.
Vene, kes tegeleb SMIT-is igapäevaselt arhitektina ka e-riigi alustalade GitOpsile liigutamisega märgib, et Eesti ettevõtted ja ka riigiasutused tunnevad selle kogemuse vastu päris suurt huvi. Miks uut lähenemist aga üldse vaja on?
Killustunud info ja tööriistad
Vajaduse GitOpsi kasutamise järele tingib Siim Vene hinnangul ka see, et hämmastavalt paljudes ettevõtetes puudub lõplik selgus selle kohta, millise seadistusega infosüsteemide tööks vajalikud serverid ja teenused on.
“Igas organisatsioonis ei ole võimalik toetuda sellele, et olemas on üks “patsiga poiss”, kes kõike peast teab,” nendib Vene.
Reaalsus on tema sõnul ka see, et kui süsteeme kasutama hakates luuakse arhitektuur ja ka tarnete kirjeldused, siis paigaldusi ja muudatusi viiakse läbi sageli käsitsi. See tähendab, et need jäävad mõnikord üldse kirjeldamata või on dokumenteeritud puudulikult. Kui aga süsteemiga midagi juhtub, siis on süsteemi töö taastamise jaoks vajalikku infot väga raske leida, see on killustunud erinevate dokumenteerimissüsteemide vahel ning võib juhtuda, et teadmine süsteemi seadistuste kohta, mis “päriselt toodangus” olemas on, puudub.
“Just see ongi koht, mida üritab adresseerida GitOps – süsteemide tarne kirjeldus konfiguratsiooni kohta on koodina deklaratiivselt kirjeldatud. Kui protsessid ja süsteemid on õigesti juurutatud, ongi see kood nii-öelda tõde, mis sul toodangus päriselt on,” toob Vene välja GitOpsi plussi, mis tagab, et tekib n-ö süsteemi elav dokumentatsioon, mis toimib ühtlasi ka taasteplaanina. Just viimane oli üks olulisi argumente, mis tõukas SMIT-i otsustama, et on vaja üle minna GitOpsi metoodikale.
“Loomulikult teevad organisatsioonid oma süsteemide taasteplaane, aga siiski tuleb alati ette probleeme, kui päriselt midagi juhtub ja on vaja hakata taastama. Kui liigume üle GitOpsi metoodikale, on konkreetse infosüsteemi konfiguratsioon ka koodina olemas ja probleemi saab lahendada näiteks viimase töötanud versiooni uuesti tarnimisega,” viitab Vene.
Lisaks kui üsna klassikaline on see, et arendusmeeskonnad peavad ettevõtetes sageli n-ö pimeduses kobama ja täpselt ei tea, mida administraatorid nende süsteemides teinud on, siis GitOps eeldab suuresti platvormiteenuste iseteeninduslikku tarbimist ja ka arendajate jaoks läbipaistvamaks muutumist. Administraatoritega suhtlemine ideaalis võiks taanduda keerulisemate lahenduste juures konsulteerimisele.
Kuidas tajub muutust tavakasutaja?
Siim Vene sõnul infosüsteemi lõppkasutaja muutust otseselt ei näe, küll aga võib see välja paista näiteks töökindlama veebirakenduse või mugavama kasutajaliidese kujul.
“Selle asemel, et kulutada aega ja energiat mingi serveri või koormusjaoturi tellimisele läbi muudatuste halduse piletisüsteemi, saavad arendajad rohkem keskenduda oma põhitööle, milleks on infosüsteemi funktsioonide arendamine – luua näiteks automaatsema ja seega kiirema piiriületuspunkti,” toob Vene näite.
Ta lisab, et tegu on n-ö nullenergiamänguga – arendaja kompetentsist on alati puudus, ning nende produktiivsust peab toetama nii palju kui võimalik, et nad saaksid päris väärtuse loomisele rohkem keskenduda.
Kui liikuda riigisektorist välja ja kõnelda ka eraettevõtetest, siis eelkõige missugused neist võiksid kaaluda üleminekut GitOpsile?
“Kõik!” on Vene konkreetne. Ta nendib, et kahtlemata nõuab GitOps meetoditele üleminek õppimist ja omajagu ressursse, aga selle toimima saamise kasu ei saa alahinnata.
SMIT-i tegutsemist selles vallas jälgitakse kõigis riigi IT-majades suure huviga. Vene avaldab, et SMIT-is vahetatakse sellealaseid kogemusi sageli näiteks Riigi Infotehnoloogiakeskusega (RIT). “Koostöö on päris tihe ja hea ning kuna RITis praegu alles arendatakse välja platvormi ja infrastruktuuriteenuseid, mis baseeruvad samamoodi GitOps põhimõtetel, siis kindlasti saab efekt olema suurem, kui SMIT-i kogemust ja õppetunde saab ära kasutada ka seal,” ütleb Vene.
Ta toob välja aga, et päris paljudes organisatsioonides on sellisel kujul protsesside digitaliseerimine ja muutused paraku aga raskendatud, sest ei jagu pädevaid spetsialiste.
Kui heita pilk näiteks 2022. aastal avaldatud OSKA uuringule, selgub, et Eestis on aastaks 2027 vaja enam kui 18 000 uut IKT-töötajat – nende seas 12 000 tarkvaraarendajat, analüütikut ja testijat.
Tallinna Tehnikaülikoolis teadvustatakse tööstuses toimuvaid trende. Näiteks IT-süsteemide administreerimise õppekavas on viimastel aastatel kasvanud skriptimise ja automatiseerimise õpetamise osakaal, kui õppetöösse põimitakse aina enam ka juba GitOpsi põhimõtteid.
Tööpõld on seega lai ja kui teema tekitas huvi, saad TalTechi IT-süsteemide administreerimise õppekava kohta lähemalt lugeda SIIT.
Vastuvõtt TalTechi on juba avatud! Avaldusi saab esitada 4. juuli keskpäevani. Vaata lähemalt: www.taltech.ee/sisseastujale.
