Centric Talks. Debesų kompiuterija (2 dalis)

Centric Talks. Debesų kompiuterija (2 dalis)

Tai, sakykim, Cloudo paslaugų teikėjai yra šiek tiek įpareigoti įstatyminės bazės, kuri įgalina galutinį vartotoją turėti tam tikrą užtikrintumą, kur yra jo duomenys, ir kad su jais nebus daroma tai, ko galbūt vartotojas nenorėtų, kad būtų daroma. Bet saugumo klausimas, vis tik išlieka. Pakalbėkim apie jį šiek tiek. Na, eiliniam Cloudo paslaugų vartotojui, turbūt mažiau rūpi, kur jo elektroniniai laiškai, svarbu, kad jie atsidarytų kiekvieną rytą sėkmingai ir ten būtų viskas, kas buvo vakar, ar ne, ir dar daugiau. Verslui, gi, iškyla tam tikrų klausimų. Na, anksčiau viskas buvo aišku, mūsų duomenys yra mūsų serveryje ir mes žinome, kur jis yra, mes žinome žmogų, kuris tą serverį prižiūri ir visada galima kreiptis į jį ir jis tuos duomenis padės gauti. Šiuo atveju gaunasi, kad duomenys įmonės, galbūt, vertingi finansiniai duomenys arba kitos komercinės paslaptys, jos padėtos kažkur tai. Ir kiek pagrįsta yra ta baimė, na, duomenys Cloude nesaugūs, juos pavogs ir galbūt jau dabar vagia?

Esu girdėjęs tokį pasakymą, kad Cloudas, kaip duomenų saugykla, nėra geresnio būdo nei saugoti duomenis kažkur savo duomenų centre. Tai, aš manau, kad tai yra netiesa, dėl to, kad, kaip kolega minėjo, Cloudo tiekėjai yra įsipareigoję saugoti tavo duomenis. Prieiga prie tų duomenų yra labai apribota, prie fizinių serverių irgi, iš tikrųjų kupina įvairiausių saugumo reikalavimų. Tai, aš manau, kad tavo duomenys Cloude yra tiek saugūs, kiek tavo Cloudo inžinierius yra teisingai sudėliojęs ir sukonfigūravęs tavo Cloudo infrastruktūrą. Ar jis nėra palikęs kokios duomenų bazės kopijos, kuri būtų viešai prieinama iš interneto, ar kažkokių nors kitų spragų. Tai tas pats lyg tu turėtum kažkokį didelį seifą ir silpniausia grandis, tikriausiai, hipotetiškai kalbant, būtų, kur tu padėjai tą raktą. Tai, manau, kad analogija būtų panaši.

Jo, sutinku su tuo, kad yra labai svarbu apsaugoti pačiam savo duomenis. Debesų paslaugų tiekėjas atsakingas yra už saugumą iki tam tikro lygmens. Tai yra, jisai yra atsakingas už fizinį saugumą, kad į tuos duomenų centrus su serveriais, nepapuls kažkokie žmonės, kurie ten neturi būti. Cloudo tiekėjai, tarp kitko, yra labai labai dažnai, periodiškai audituojami skirtingų organizacijų ir turi visą eilę medalių ir orderių, tai yra, audito kažkokių ataskaitų, kuriose sakoma, kad taip, šitas paslaugų tiekėjas yra atitinkantis kažkokį ISO 27001, hpps ar kažkokį kitą saugumo standartą. Tai, kalbant jau kas yra serverių viduje, tai debesų paslaugų tiekėjas konfigūruoja tas savo paslaugas, kuriomis mes naudojamės, na, sakykim, kad mes elementarią, virtualią mašiną galėtume keliais paspaudimais paleisti. Tai, jisai yra atsakingas ir už tai, kad nėra palikta kažkokių tos virtualios mašinos valdymo sistemoje spragų, bet iš kitos pusės, mes, kaip klientai, jau esam galutinai atsakingi už tą informaciją ir kaip mes ją sukonfigūruosime, kaip Aurelijus minėjo. Ir dažnai, ypač anksčiau, prieš metus, prieš kelis metus, būdavo galima matyti antraštes tokias, kad tokios ir tokios kompanijos duomenys nutekėjo, laisvai buvo prieinami visiems ir būtinai būdavo paminėta, kad tie duomenys buvo Cloude kažkokiam, Azure, AWS ar dar kažkur. Bet tiktai pasižiūrėjus, paskaičius tą naujieną, paaiškėdavo, kad, na iš tiesų, tiesiog tie, kas konfigūravo, kaip tie failai bus prieinami, leido bet kam prieiti prie tų failų. Tai čia 99 proc, ko gero, tų pažeidimų nutinka dėl pačių vartotojų kaltės ar klaidos. Ir, iš tiesų, tai yra, na, galbūt ir galima to tikėtis, jeigu žmogus – administratorius, inžinierius, kuris rūpinosi ilgą laiką savo on premise instrastruktūra, perkeliamas dirbti prie Cloudo. Konceptai šiek tiek skiriasi, atsiranda visa ta valdymo plotmė, tas management plain, kur reikia dėti teises kažkokias vartotojams valdyti, tai galbūt į kai kuriuos niuansus jis ir neatsižvelgia. Ar pamiršta, ar nežino. Ir Cloudo provideriai dėl to, na, aišku, jie tą pastebėjo ir jie nenori, kad jų klientai būtų pažeidžiami, kad jų duomenys nutekėtų. Dėl to jie ir pradėjo nemažai siūlyti paslaugų, rekomendacijų. Kažkokie saugumo centrai, kurie skanuoja mūsų infrastruktūrą ir praneša, ką galbūt būtų galima patobulinti. Ir, na, tos priemonės, iš tiesų, padeda mums apsaugoti tuos duomenis ir jaustis tame Cloude taip pat užtikrintai, kaip kad jaustumėmės on premise.

Jo, turbūt žmogiškasis faktorius yra turbūt lemiamas saugumo aspektas. Tik aš norėčiau pabrėžti, kad migruojant savo infrastruktūrą į Cloudą, turbūt, pamirštama ne tik, dirbame tik su technologija, bet, tikriausiai pamirštama, kad yra dar dvi dedamosios, kurios yra labai svarbios. Tai yra žmonės, ir yra procesai. Tai, jeigu mes migruojam savo visą infrastruktūrą, aplikacijas į Cloudą, reikia nepamiršti, kad ta migracija tuo nepasibaigia. Visą infrastruktūrą ir aplikacijas dar reikia prižiūrėti. Tai reikia edukuoti savo inžinierius, kad jie mokėtų dirbti su Cloudu, mokėtų tai daryti gerai. Ir reikia turėti procesus, kurie leistų prižiūrėti tą infrastruktūrą. Galbūt reikalinga atskira palaikymo komanda, galbūt kažkokie nauji procesai, nes tai šiek tiek keičiasi.

Labai sklandžiai perėjome prie klausimo, kurį kaip tik ir norėjau užduoti. Kuo skiriasi tas infrastruktūros inžinierius arba sistemų administratorius, kaip mes anksčiau suprasdavome, nuo Cloudo inžinieriaus? Ar tai visiškai skirtingos respublikos, ar, vis tik tai, yra kažkokia tai, na, yra kažkokia bendrystė tarp jų?

Ko gero, sakyti, kad tai skiriasi kardinaliai, na, mes tikrai negalim. Bet, bet kokiu atveju, pagrindinė užduotis, ko gero, tiek Cloud inžinieriaus, tiek sistemų inžinieriaus, kuris dirba su sistemomis, na, mūsų vidiniam duomenų centre, tai jų atsakomybės yra užtikrinti, kad tos sistemos sklandžiai veiktų, galbūt efektyvinti, kaip tos naujos sistemos yra paleidžiamos, tačiau šiek tiek skiriasi, kaip tai yra atliekama. Cloudo atveju mes turime, kaip kalbėjom, kiekvienas Cloudo provideris turi apie porą šimtų skirtingų paslaugų. Ir Cloudo provideriai stengiasi, kad tas paslaugas naudoti būtų kuo paprasčiau, na, elementariai, tiesiog jie taip pat nori, kad kuo daugiau žmonių naudotųsi tomis paslaugomis. Ir operuojama paprastai Cloude jau šiek tiek didesniais blokais, tai yra, kažkokiom paslaugom, po kurių apačia gali būti jau daug sudėtingų aplikacijų sistemų, tačiau jų konfigūravimu jau yra pasirūpinęs Cloudo tiekėjas. Jeigu kalbam apie sistemų inžinierių, kuris on premise infrastruktūrą prižiūri, jam paprastai tenka operuoti šiek tiek mažesnėmis kaladėlėmis, tenka atlikti daugiau konfigūracijos, na, nežinau, galim kalbėti apie tą patį identity valdymą kažkokį, kaip turėjom active directory, tada galbūt kažkokį OAuth ar SAML autentikacijos federavimo servisą. Visa tai turėdavo daryti inžinierius pats – diegti serverius, konfigūruoti, kai Cloudo atveju, jeigu mes paimtume Azure ID, visa tai galima įgyvendinti labai greitai. Tai vienas iš tokių skirtumų, gal didžiausių net skirtumų būtų, tiesiog kokio dydžio blokais tu operuoji, kai konfigūruoji vieną ar kitą paslaugą.

Jo, kaip Dovydas minėjo, Cloudo inžinieriai tai tampa jau kaip ir profesija. Galbūt ne visai sistemų administratorius tampi, o Cloudo inžinierius ir tu dirbi daugiau jau tam loginiam lygmeny negu, kad, pavyzdžiui, sistemų administratoriai. Jiems kartais tekdavo nueiti ištraukti kokį nors diską, patikrinti reidą, pakonfigūruoti ar dar kažką, tai šito dalyko jau Cloudo inžinieriams daryti nebereikia, jie dirba su virtualizuotais ir dar abstrakcijos lygmeny visais loginiais elementais – ar tai, su Cloudo teikiamom paslaugom – virtualios mašinos, tinklai ir panašiai. Tai mažesnėm kompanijom, galbūt yra patogiau naudotis portalu, kuris teikia Cloudo tiekėjas, kur tu gali vizualiai matyti, ką tu kuri ir kaip tu dėlioji. Bet didesnėm kompanijom, kurios tikrai nori išnaudoti visus Cloudo teikiamus privalumus, joms, manau, kad yra būtina savo Cloudo inžinierius išmokyti dirbti kodo lygmeny, kuomet tu rašai savo infrastruktūrą kaip kodą. Tai vadinasi infrastructure as a code. Tu aprašai kaip nori, kad atrodytų infrastruktūra, kokie jos elementai, kaip jinai skeilinasi – didėja ar mažėja ir panašiai. Ir tą kodą paleidus, ta infrastruktūra Cloude susigeneruotų ir susikurtų automatiškai. Tai, manau, tiek mažoms, tiek didesnėms įmonėms, kurios migruoja į Cloudą, yra labai naudinga pagreitinti savo testavimą ir išleidimą į produkciją procesus.

Ir dar galbūt paminėsiu, kad Cloudo provideriai iš tiesų rūpinasi, kad būtų tie įrankiai, kurie leistų infrastruktūrą kaip kodą rašyti. Nes, vėlgi, tai yra nauda klientui, tiek ir jiems, kadangi kitu atveju pas juos daugiau kas ateis.

Kitaip sakant, infrastructe as a code, jeigu visą savo infrastruktūrą apsirašome kodo pavidalu, tai mes galime Cloude savo turimą infrastruktūrą sugriauti ir paleidus iš naujo deploymentą su mūsų infrastructure as a code, galima tą infrastruktūrą tuoj pat pasistatyti atgal.

Taip, mes galim turėti visiškai identišką konfigūraciją negu prieš tai turėjom ir, na, tai kartu leidžia išvengti žmogiškųjų klaidų. Nes tą pačią konfigūraciją suspaudyti mygtukais rankomis gali, na, vis tiek greičiausiai įsivelti kažkokių klaidų. Neskaitant to, kad tai gana lėtas procesas būtų.

Kitaip sakant, suspaudyti galima, bet tai būtų labai neefektyvu.

Taip.

Gerai. O tada kalbant apie Cloudo inžinieriaus profesiją – ką reikėtų mokėti arba kur reikėtų gilinti savo žinias norint tapti Cloud inžinieriumi?

Na, turbūt, pats lengviausias atsakymas būtų, tai išmokti Cloudo tiekėjų teikiamas paslaugas. Ką jos daro, kodėl tau to reikia ir kaip tai turėtų veikti. Na, iš esmės, šiek tiek Cloudo architektūros. Jinai šiek tiek skirsis negu aplikacija, kuri turėjo savo architektūrą on premise vadinamam duomenų centre. Tai, manau, kad suprasti Cloudo tiekėjų siūlomas paslaugas yra labai svarbu, kad galėtum sukurti tokią infrastruktūrą, kuri kuo labiau išnaudotų visas Cloudo teikiamas paslaugas ir visas naudas.

Tuo pačiu, aišku, yra tos žinios, kurias turi tipinis, sakykim, sistemų inžinierius ar sistemų administratorius, jos taip pat yra be galo vertingos. Kai tu žinai, kaip žemam lygmeny veikia tinklai, duomenų saugyklos, virtualizavimas. Taip, tau nebetenka operuoti tame lygmenyje, kai tu persikeli į Cloudą ir ten galbūt šiek tiek skiriasi, kai aš kuriu savo virtualų tinklą, potinklius, kažkokias Network security grupes priseginėju. Bet žinojimas, kaip viskas veikia po kapotu, manau, taip pat yra labai svarbu auginantis savo kompetencijas ir iš tiesų suprantant, kaip tas Cloudas veikia ir ką galbūt reikėtų naudoti vienoj ar kitoj situacijoj. Plius, Cloudo inžinieriai dažnai rūpinasi migravimo procesais ir jie kelia paprastai aplikacijas iš tų on premise sistemų. Reiškia, žinios tikrai padės ir modernizuojant galbūt tą aplikaciją ir ją migruojant į Cloudą.

Tai būtent. Dar papildant, kadangi, kaip minėjau, Cloud inžinieriai dažniausiai rašo infrastruktūrą kaip kodą, infrastructure as a code, tai gali pasirodyti, kad, na, tai jie tiesiog programuotojai. Jo, tai iš tikrųjų, Cloud inžinieriai savo kodą laiko kodo versijavimo sistemoje, pavyzdžiui, GIT ar kažkas panašaus. Ir jie, na, tą aprašymą infrastruktūros, jie laiko, kad, na, tai iš tiesų yra programinis kodas ir su juo taip elgiasi.

Ir taip pat jie galbūt ir įrankius savo rašo, kurie padeda, na, su kažkokiais produktais dirbti. Kažkokiam, na, nežinau, monitorinimo sistemom providerius rašo arba, na, kažkokias smulkias dedamąsias dalis, kurios neegzistuoja, mes jas galime irgi laikyti kažkokiais scriptais ar programinės įrangos komponentais, kurie padeda visą darbą atlikti daug greičiau ir efektyviau.

Taip. Kadangi tas infrastructure as code approach‘as nėra labai toks jau toks senas dalykas, gal nėra pats naujausias, bet šiuo metu jis yra kaip ir ant bangos, mes asmeniškai pastebėjom, kad nėra labai daug gerų ir gerai veikiančių įrankių ištestuoti tą savo kodą. Tai irgi kažkas, prie ko kiekvienas Cloud inžinierius galėtų prisidėti. Tai konfigūruoti ir sugalvoti kažkokią sistemą, kuri galėtų padėti ištestuoti infrastruktūrą, kurią tu ketini pastatyti. Ar jinai pastačius veiks taip, kaip tu tikėjaisi ir darys tą, ką tu norėjau, kad ji darytų. Tai vėlgi, mokėti rašyti scriptus ar naudotis kažkokiomis programavimo kalbom yra tikrai pranašumas, nes tu gali kurti savo įrankius.

Tai susumuokim, ką turim. Išeina taip, kad Cloudinės paslaugos leidžia eliminuoti tą mūsų vadinamąjį hardware lygį, kai nereikia rūpintis nei serverių diskais, nei pačių serverių nereikia pirkti, nei kabelių vedžioti ir kaišioti, tai yra atsisakoma viso to darbo, kurį anksčiau sistemų administratoriai suprasdavo kaip pagrindinį ir savaime suprantamą. Lygiai taip pat infrastruktūros pakūrimas Cloude galimas infrastruktūros kaip kodo metodu, tai reiškias yra parašytas kodas, kurį užtenka paleisti ir visas tas dalykas susikuria. Iš to kyla natūralus klausimas – ar tai reiškia, kad infrastruktūrinės komandos ateityje nebus reikalingos versle? Nes kam jos reikalingos, jeigu serverių prižiūrėti nereikia ir tiesiogiai kurti resursų Cloude irgi nereikia?

Nežinau. Jeigu, čia mano asmeninė nuomonė, aišku, jeigu mes kalbame pakankamai toli į ateitį, sakykim, nežinau, na, duriu pirštu ir sakau, ko gero dešimt metų plius, galbūt tai yra netgi ir tiesa. Bet kol kas bent jau ir kiek numatoma, sakykim, ateinantiems keliems metams, tai, kas dabar vyksta – migravimai visi, Cloudo adoption rate‘as vis dar ypač didelėse įmonėse nėra galbūt toks, koks galėtų būti. Ir tų įmonių vadovai galbūt norėtų, kad jis būtų didesnis. To darbo yra pilna ir dar jo bus tikrai pilna kuriam laikui. Dešimt metų, galbūt, pagalvojau, šiek tiek yra per daug optimistiška.

Jo.

Galutiniam variante, manau, kad taip, prieisim prie to, kad vienintelis fokusas būtų kuriant kažkokį IT produktą, rašyti galbūt jo kodą ar netgi nerašyti kodo, o dėlioti kažkokius kvadratėlius, komponentus ir naudoti tą no code approach‘ą. Bet iki kol tai bus vienintelis būdas, kaip mes kuriam kažkokius produktus, na, čia dar turėtų praeiti labai labai daug laiko ir, tikėtina, kad aš galbūt ir nesulauksiu šito jau. Nors...

Būk optimistas.

Galiu pabūt optimistas.

Bet, Dovydai, iškart kilo klausimas. Tai tikriausiai tokie kaip sistemų inžinieriai bus reikalingi statant tuos duomenų centrus ir darant jų integraciją ir apjungimą. Nebent prigyvensim iki tokio laiko, kai tai bus automatizuota ir machine learningas pats tuos tinklus sujungs. Bet čia...

Jo, aš sutinku su tuo. Tik vėlgi, galvojant apie public Cloudą ir jo didėjančią rinkos dalį, tie duomenų centrai tampa šiek tiek labiau konsoliduoti. Jie atsiranda pas iki dešimties didelių žaidėjų labai. Tai tie darbai, ko gero, yra pakankamai mažai daliai žmonių patikimi. Dėl infrastruktūros priežiūros Cloude, tai taip greitai niekas nepasikeis. Kol mes priėjom dabar tokį Cloudo adoption rate‘ą, kokį mes turim dabar, kuris yra jau pakankamai nemažas, bet vis dar galbūt galėtų būti didesnis, tai praėjo kiek, apie penkiolika metų, ko gero. Nuo to tikro public Cloudo atsiradimo. Tai praeis dar tikrai nemažiau laiko, kol, na, tie Cloud inžinieriai galbūt taps tiesiog programinės įrangos inžinieriais ir jų darbo profilis šiek tiek pasikeis vėl, kaip pasikeitė IT administratorių darbo profilis į Cloudo inžinierius.

Norint tapti, na, jaunam žmogui galbūt su technologine pakraipa jo studijų, tarkim, informatikos studentas, norint tapti Cloudo inžinierium, į kokias sritis arba kokias disciplinas jam vertėtų atkreipti dėmesį labiau? Ką jis turėtų pasimokyti?

Jo. Tai greičiausiai viena iš sričių būtų virtualizacija. Kad ir kiek giliai jinai Cloude yra paslėpta, suprasti, kaip veikia virtualizuoti resursai ir kas tai yra, kuo jie skiriasi nuo vieno fizinio serverio su viena operacine sistema iki fizinio serverio su hipervizoriais, virtualiom mašinom, konteineriais ir panašiai. Tas supratimas tikrai padėtų. Tai pat, manau, labai reikalingas supratimas apie aplikacijas, apie programas. Ne grynai apie patį programavimą, bet kaip aplikacija veikia infrastruktūroje, kokios galimos architektūros konfigūracijos, kokie susijungimai su duombazėm, kokie yra sąryšiai ir panašiai.

Aš gal dar pridėčiau saugumo aspektą. Tai be to, ko gero, neišsiversim niekaip. Nes tų pažeidžiamumų, bandymų įsilaužti tikrai nemažėja pastaraisiais metais. Ir, jeigu kartais, kad ir kaip retai atsiranda tie pažeidžiamumai, tikri pažeidžiamumai pas public Cloudo providerius, taip, jų irgi pasitaiko, bet jeigu, vis dėl to išlįstų kažkoks stambus pažeidžiamumas ir, turint omeny, kiek daug klientų turi didieji Cloudo provideriai, na, tai galėtų būti pakankamai rimta problema ne vienai įmonei.

Dar norėčiau paminėti, kad beveik visi Cloudo tiekėjai siūlo vieno mėnesio arba tam tikro kiekio resursų nemokamas prenumeratas. Tai yra lengvas ir geras būdas pradėti naudotis to Cloudo tiekėjo paslaugom ir iš tikrųjų išsibandyti netgi įvairiausius Cloudo tiekėjus, pasižiūrėti, koks tarp jų skirtumas. Tai tu sukuri prenumeratą, tu prisijungi ir tu turi tam tikrą nemokamą kiekį resursų arba tai būtų kreditai, ar būtų tiesiog pinigai nustatyti, 50 ar 100 eurų, ir juos išnaudoti toms Cloudo paslaugoms pasibandyti susikurti serverį gal duombazę, gal juos viduj kažką paleisti, galbūt kažkokį kitokį servisą. Tai galimybės pradėti ir netgi visai pigiai, tikrai yra galimos.

Ir, svarbiausia, ko gero, yra bandyti daryti.

Taip, svarbiausia yra daryti.

Tai ačiū kolegoms labai už skirtą laiką. Su mumis šiandien studijoje buvo kolega Aurelijus, komandos vadovas, ir mūsų kviestinis svečias Dovydas, Cloudo ekspertas. Labai džiaugiamės galėdami apie tai pakalbėti. O klausytojams ir žiūrovams linkim gero savaitgalio ir iki kitų susitikimų.

Iki.

Iki.