Ilgą laiką besidarbuodami su didžiausiais automobilių gamintojais kompanija augino savo produktų portfelį ir paslaugų spektrą. Deja, kaip kartais nutinka didelėms IT kompanijoms, produktų vystymas nebūtinai žengia koja kojon su IT infrastruktūros pažanga, todėl prašymo padėti sulaukė JAV programavimo paslaugų įmonės „Devbridge“ DevOps inžinieriai, kurie daugiau nei metus darbavosi, kurdami visiškai naują sistemą, padedančią aptarnauti kompanijos klientus.
Įžvalgomis apie priimtą sudėtingą iššūkį dalijasi JAV programavimo paslaugų įmonės „Devbridge“ DevOps praktikų vadovas Marius Guobys.
– Kodėl didžiausias pasaulyje automobilių aptarnavimo IT sprendimų tiekėjas pasirinko būtent Jus?
– Ilgą laiką besidarbuodami su didžiausiais automobilių gamintojais kompanija augino savo produktų portfelį ir paslaugų spektrą. Mūsų klientas padeda savo partneriams, kurdamas naujos kartos aplikacijas ir IT sprendimus, apimančius kone visą automobilio įsigijimo ciklą – nuo skaitmeninių pardavimo platformų, santykių su klientais valdymo (CRM) ir pardavimo salonų operacinės dalies efektyvumo užtikrinimo. Kompanija teikia savo klientams ir jų verslui naudingas įžvalgas, pasitelkdama reikiamus duomenis, kurie paremti pažangiais analitiniais sprendimais ir dirbtiniu intelektu.
Tačiau daug metų besidarbuojant su partneriais ši kompanija susidūrė su keliomis problemomis. Pirmoji problema buvo susijusi su tuo, kad didžioji dalis produktų tapo neišvaizdūs ir ganėtinai pasenę, žvelgiant iš dizaino ir vartotojo perspektyvos, tad čia pasidarbuoti teko mūsų „Front-end“ inžinieriams. Kitas projektas prie kurio mums teko prisidėti – visiškai naujos sistemos sukūrimas, padedantis aptarnauti kompanijos klientus. Ir trečiasis, didžiausias projektas, prie kurio intensyviai darbavomės daugiau nei metus buvo susijęs su debesijos sprendimų panaudojimu, pertvarkant nusistovėjusį jų IT ūkį.
– Jūsų kliento verslo plėtrą stipriai pristabdė senos technologijos, nuo ko pradėjote pertvarkos darbus?
– Per daugelį darbo metų kliento IT infrastruktūra evoliucionavo. Iš pradžių kompanija įkūrė savo duomenų centrus, kuriuose įrengė didelius kiekius serverinių, kuriose ir buvo laikomi bei aptarnaujami visi kompanijos sukurti produktai. Natūrali evoliucija, kuri po to įvyko – virtualizacija. Kai esamus serverius kompanija virtualizavo ir ilgus metus šis priėjimas puikiai veikė be problemų ir visi buvo patenkinti. Tačiau po kurio laiko kompanija atsimušė į produktų augimo ir IT ūkio vystymosi sieną.
Problema, kurią sukūrė natūrali produktų evoliucija ir augimas lėmė tai, kad kelerius metus nebuvo per daug didelio planavimo į priekį. Kiekvienais metais klientų ratas plėtėsi ir augo ne vienetais, bet dešimtimis ir šimtais. Dėl turimų produktų architektūros kiekvienam klientui kompanija diegė dedikuotą virtualią mašiną su savais resursais bei visais reikiamais komponentais. Todėl virtualių mašinų kiekis išaugo tūkstančiais. Visa tai sukūrė nemažai bėdų, o tai reikėjo suvaldyti. Kai turimi tokie dideli kiekiai virtualių mašinų tampa sunku jas stebėti, atnaujinti, diegti produktų atnaujinimus.
– Spartų augimą stabdė pasenusi IT infrastruktūra, kaip pavyko įgyvendinti pokytį?
– Buvo pasirinkta strategija keliauti mikroservisų architektūros principu ir konsoliduoti išsibarsčiusias klientų produktų versijas taip, jog nebūtų pagamintas didelis monstriškas monolitas, tačiau būtų išnaudojami visi mikroservisų privalumai.
IT infrastruktūros architektūra turėjo būtų perdaryta iš esmės. Tapo aišku, kad augti toliau, didinant virtualių mašinų kiekius nepavyks. Tad buvo nuspręsta rinktis technologijas, kurios atitiktų produktų vystymo architektūrą. Čia buvo pasirinktas konteinerizavimo kelias, panaudojant tokias technologijas kaip Docker. Bet kadangi neužtenka tik puoselėti konteinerių technologiją, tačiau reikia ir užtikrinti, jog šie konteineriai būtų lengvai valdomi ir prižiūrimi. Todėl kartu su Docker papildomai buvo pasirinkta technologija Kubernetes, kuri leidžia užtikrinti konteinerių pasiekiamumą, saugumą ir lengvesnę priežiūrą.
Tačiau teko išspręsti ir dar vieną uždavinį: kur mes šią konteinerizacijos sistemą diegsime? Galima buvo išnaudoti esamus duomenų centrus, bet tai reikalauja naujų serverių įsigijimo, jų įrengimo. Mūsų klientas greitai suprato, kad neturi daug laiko užsiimti konteinerių technologijos vystymu savo duomenų centruose, tad buvo nuspręsta panaudoti debesijos sprendimus bei buvo pasirinktas Amazon debesijos sprendimas AWS (angl. Amazon Web Services).
– Kokie technologiniai sprendimai labiausiai pasiteisino ir atnešė daugiausiai naudos klientui?
– Kadangi pasitelkus Kubernetes technologiją buvo planuojama vystyti šimtus produktų, kurie tarpusavyje bus apjungti ir reikės užtikrinti jų saugumą. Tad visa tai reikalavo dar vieno papildomo lygmens – vadinamo Service Mesh technologija. Service Mesh technologijos pasitelkimas mums palengvino produktų saugos užtikrinimą, tuo pačiu Service Mesh technologija leido vykdyti lengvą komunikacijos stebėseną – t.y. mes galime realiu laiku matyti, kur koks produktas jungiasi ir kokias komunikacijas tarpusavyje užmezga. Tai mums leido greičiau identifikuoti potencialias problemas ir jas išspręsti. Kai nustatėme visus IT infrastruktūros standartus ir technologijas – konteinerizacija, Kubernetes, AWS, Service Mesh. Atėjo laikas tuo pačiu ir pasirinkti kaip mes visa tai diegsime – pasirinkome automatizacijos kelią. Tuo tikslu panaudojome Terraform įrankį, kuris padėjo lengvai automatizuoti sprendimus, kuriamus debesijoje.
– Ar daug iššūkių kėlė naujų technologijos įsisavinimas? Kaip į šiuos pokyčius reagavo klientas?
Po IT infrastruktūros architektūros ir sprendimų pasirengimo, tuo pačiu buvo nuspręsta ir automatizuoti visą produktų išleidimo ir atnaujinimo procesą (angl. Continous Integration and Delivery). Tai mums leido automatizuotu būdu diegti naujus produktus į kuriamą konteinerizacijos sprendimą bei juos lengvai atnaujinti, diegti naujus patobulinimus. Tokios bendros sistemos vystymas yra tęstinis procesas. Todėl vystėme šį projektą daugiau nei metus: viską sistemingai dokumentavome, apmokėme kliento darbuotojus ir tolimesnį sistemos vystymą perdavė jiems.
– Nors klientas yra milžiniško dydžio įmonė, dirbote vos septyniese. Kokie buvo didžiausi iššūkiai?
Didžiausi iššūkiai kilo įsisavinant naujas technologijas – konkrečiai Service Mesh ir viską, kas susiję su šia technologija. „Devbridge“ komandai – tai buvo pirmas didelis projektas, kur mes galėjome realizuoti sprendimą, panaudojant šią technologiją. Mūsų klientui tai buvo visiškai nauja sritis, tad teko tikrai daug paplušėti dirbant su kliento komanda. Viskas vyko pandemijos įkarštyje. Tad dirbome nuotoliniu būdu, su klientu buvome susitikę tik per vaizdo konferencijos skambučius, tačiau tai nesutrukdė pasiekti puikių rezultatų.
– Ką patartumėte kitoms įmonėms, galbūt dirbančioms Lietuvoje ir galvojančioms apie IT infrastruktūros plėtrą?
– Bet kuriai didžiulei kompanijai yra naudinga perkelti tuos tūkstančius produktų į vientisą sistemą, kuri turi apibrėžtą architektūrą, technologijas, kur yra aiškus jų vystymas ir tolimesnis taikymas. Tai padeda sutaupyti kaštus, laiką ir efektyviau dirbti komandoms. Tačiau daug svarbesnis tikslas, kuris yra pasiektas yra tai, kad produktų vystymas ir išleidimas ženkliai paspartėja.
Žinoma, reikia nepamiršti, kad tokios sistemos, kaip ir bet kokio kito produkto laukia natūrali evoliucija ir vystymas. Reikės augti kartu su produktais, kurie ten diegiami, diegti naujas galimybes palaikyti šiems produktams. Taip pat nepamiršti ir kasdienių darbų – pati sistema reikalauja periodinių atnaujinimų ir palaikymo. Įrankiai, kurie naudojami sistemos valdymui ir automatizacijai, taip pat turi būti palaikomi ir atnaujinami. O žvelgiant į dar tolimesnę ateitį, mes jau turėjome planų kaip sistemą klonuosime skirtinguose žemynuose. Tad, pavyzdžiui, klientai Šiaurės Amerikoje naudosis sistema, kuri yra Š. Amerikos AWS debesijoje, o štai Azijoje įsikūrę klientai naudos Azijos versiją ir t.t. Tad planų ir idėjų daug – svarbu laikytis numatyti tikslų ir augti neatsiliekant nuo sistemos klientų poreikių – t.y. produktų.
