25. aprillil pidasime Mail.ru Grupis konverentsi pilvedest ja selle ümbrusest - . Mõned esiletõstmised:
- Peamine — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecomi andmekeskus ja Yandex.Cloud rääkisid meie pilveturu ja oma teenuste eripäradest;
- Kolleegid Bitrix24-st rääkisid, kuidas nad ;
- Huvitavat pakkusid Leroy Merlin, Otkritie, Burger King ja Schneider Electric — milliseid ülesandeid nende ettevõte IT-le seab ja milliseid tehnoloogiaid, sealhulgas pilvetehnoloogiaid, peavad nad kõige lootustandvamaks.
Saate vaadata kõiki mailto:CLOUD konverentsi videoid , ja siit saab lugeda, kuidas mikroteenuste arutelu kulges. MegaFoni ärisüsteemide uurimis- ja arenduskeskuse juht Aleksander Deulin ja M.Video-Eldorado grupi infotehnoloogia direktor Sergey Sergeev jagasid oma edukaid monoliitidest vabanemise juhtumeid. Arutasime ka IT-strateegia, protsesside ja isegi personalivaldkonna teemasid.
Panelistid
- Sergei Sergejev, Grupi CIO "M.Video-Eldorado";
- Aleksander Deulin, ärisüsteemide uurimis- ja arenduskeskuse juhataja MegaFon;
- Moderaator - Dmitri Lazarenko, PaaS suuna juht Mail.ru pilvelahendused.
Pärast Aleksander Deulini kõnet temaga liituvad aruteluks Sergey Sergeev M.Video-Eldoradost ja arutelu moderaator Dmitri Lazarenko, Mail.ru Cloud Solutions.
Allpool oleme teile koostanud arutelu ärakirja, kuid saate vaadata ka videot:
Mikroteenustele üleminek on vastus turu vajadustele
Dmitri:
Kas teil on olnud edukaid kogemusi mikroteenustele üleminekul? Ja üldse: kus näete mikroteenuste kasutamisest või monoliitidelt mikroteenustele üleminekust suurimat ärilist kasu?
Sergei:
Oleme mikroteenustele üleminekul juba mingil määral jõudnud ja seda lähenemist kasutanud juba üle kolme aasta. Esimene vajadus, mis õigustas mikroteenuste vajadust, oli erinevate esiotsa toodete lõputu integreerimine tagakontoriga. Ja iga kord olime sunnitud tegema täiendavat integreerimist ja arendust, rakendades selle või selle teenuse toimimiseks oma reegleid.
Mingil hetkel saime aru, et peame oma süsteemide tööd ja funktsionaalsuse väljundit kiirendama. Sel hetkel olid sellised mõisted nagu mikroteenused ja mikroteenuste lähenemine turul juba olemas ning otsustasime seda proovida. See sai alguse 2016. aastal. Seejärel pandi platvorm paika ja esimesed 10 teenust viis ellu eraldi meeskond.
Üks esimesi, enim koormatud teenuseid, oli hinna arvutamise teenus. Iga kord, kui tulete ükskõik millisesse kanalisse, M.Video-Eldorado ettevõtete gruppi, olgu selleks veebisait või jaekauplus, valite sealt toote, näete hinda veebisaidil või “Korvis” arvutatakse ühe teenuse järgi. Miks see vajalik on: enne seda olid igal süsteemil oma põhimõtted tutvustustega töötamiseks - allahindlustega ja nii edasi. Meie tagakontor tegeleb hinnakujundusega, allahindlusfunktsioonid on rakendatud teises süsteemis. See tuli tsentraliseerida ja luua äriprotsessi kujul ainulaadne, eraldatav teenus, mis võimaldaks seda rakendada. Umbes nii me alustasime.
Esimeste tulemuste väärtus oli väga suur. Esiteks saime luua eraldatavad üksused, mis võimaldavad meil töötada eraldi ja koondatult. Teiseks oleme vähendanud omamiskulusid integreerimisel rohkemate süsteemidega.
Viimase kolme aasta jooksul oleme lisanud kolm eesliinisüsteemi. Neid oli keeruline ülal pidada sama ressurssidega, mida ettevõte endale lubas. Seetõttu tekkis ülesanne otsida uusi turustusvõimalusi, reageerides turule nii kiiruse, sisemiste kulude kui ka efektiivsuse poolest.
Kuidas mõõta mikroteenustele ülemineku edukust
Dmitri:
Kuidas määratakse edu mikroteenustele üleminekul? Mis oli igas ettevõttes "enne"? Millist mõõdikut kasutasite ülemineku edukuse määramiseks ja kes selle tegelikult määras?
Sergei:
Esiteks sündis see IT-s kui võimaldaja – uute võimaluste “avamine”. Meil oli vajadus turuprobleemidele reageerides suhteliselt sama raha eest kõike kiiremini teha. Nüüd väljendub edu erinevates süsteemides taaskasutatud teenuste arvus, protsesside omavahelises ühendamises. Nüüd on, aga tol hetkel oli võimalus luua platvorm ja kinnitada hüpotees, et saame hakkama, see annab efekti ja arvutab välja ärilise juhtumi.
Aleksander:
Edu on pigem sisemine tunne. Ettevõtlus tahab alati rohkem ja meie mahajäämuse sügavus on edu tõestuseks. Mulle tundub nii.
Sergei:
Jah, ma nõustun. Kolme aastaga on meil juba üle kahesaja teenuse ja mahajäämuse. Meeskonnasisene ressursivajadus ainult kasvab – 30% aastas. See juhtub, sest inimesed tundsid: see on kiirem, see on teistsugune, on erinevad tehnoloogiad, see kõik areneb.
Mikroteenused tulevad, aga tuum jääb alles
Dmitri:
See on nagu lõputu protsess, kus sa investeerid arengusse. Kas üleminek ettevõtlusele mõeldud mikroteenustele on juba lõppenud või mitte?
Sergei:
Sellele on väga lihtne vastata. Mida arvate: telefonide väljavahetamine on lõputu protsess? Ise ostame telefone igal aastal. Ja siin see on: seni, kuni on vaja kiirust, turuga kohanemist, on vaja mõningaid muudatusi. See ei tähenda, et me standardasjadest loobuksime.
Kuid me ei saa kõike korraga katta ja ümber teha. Meil on pärand, standardsed integratsiooniteenused, mis eksisteerisid varem: ettevõtete bussid ja nii edasi. Aga mahajäämus on olemas ja vajadus on ka olemas. Mobiilirakenduste arv ja nende funktsionaalsus kasvab. Samas ei ütle keegi, et sulle antakse 30% rohkem raha. See tähendab, et ühelt poolt on alati vajadused ja teiselt poolt efektiivsuse otsimine.
Dmitri:
Elu on heas seisus. (Naerab)
Aleksander:
Üldiselt jah. Meil ei ole revolutsioonilisi lähenemisviise põhiosa maastikult eemaldamiseks. Süstemaatiline töö käib süsteemide dekomponeerimiseks nii, et need oleksid mikroteenuste arhitektuuriga paremini kooskõlas, et vähendada süsteemide mõju üksteisele.
Kuid plaanime põhiosa alles jätta, kuna operaatori maastikul on alati mõni platvorm, mida ostame. Jällegi vajame tervislikku tasakaalu: me ei tohiks kiirustada tuuma välja lõikamisega. Asetame süsteemid kõrvuti ja nüüd selgub, et oleme juba paljude põhiosade peal. Edasi funktsionaalsust arendades loome vajalikud esindused kõikidele kanalitele, mis meie sideteenustega töötavad.
Kuidas müüa ettevõtetele mikroteenuseid
Dmitri:
Olen ka huvitatud - neile, kes pole ümber vahetanud, kuid plaanivad: kui lihtne oli seda ideed ärile müüa ja kas see oli seiklus, investeerimisprojekt? Või oli see teadlik strateegia: nüüd läheme mikroteenuste juurde ja ongi kõik, meid ei takista miski. Kuidas sul läks?
Sergei:
Me ei müünud lähenemist, vaid ärikasu. Äris tekkis probleem ja me püüdsime seda lahendada. Sel hetkel väljendus see selles, et erinevad kanalid kasutasid hindade arvutamisel erinevaid põhimõtteid - eraldi kampaaniate puhul, kampaaniate puhul jne. Seda oli raske hooldada, esines vigu ja kuulasime klientide kaebusi. See tähendab, et müüsime probleemile lahendust, kuid tulime sellega, et vajame platvormi loomiseks raha. Ja nad näitasid ärilist näidet investeeringu esimese etapi näitel: kuidas me jätkame selle tasumist ja mida see võimaldab meil teha.
Dmitri:
Kas panid esimese etapi aja kuidagi kirja?
Sergei:
Jah muidugi. Eraldasime 6 kuud, et luua tuum platvormina ja testida pilooti. Selle aja jooksul proovisime luua platvormi, millel piloot uisutada. Siis sai hüpotees kinnitust ja kuna see töötab, siis saame jätkata. Nad hakkasid meeskonda kordama ja tugevdasid – nad viisid selle eraldi divisjoni, mis just seda teeb.
Edasi tuleb süsteemne töö, mis lähtub ärivajadustest, võimalustest, ressursside olemasolust ja kõigest sellest, mis parasjagu töös on.
Dmitri:
OKEI. Aleksander, mida sa ütled?
Aleksander:
Meie mikroteenused sündisid “merevahust” – tänu ressursside säästmisele, mõningatele ülejääkidele serverimahu ja meeskonnasisese jõudude ümberjaotamise näol. Esialgu me seda projekti ärile ei müünud. See oli projekt, kus me nii uurisime kui ka arendasime vastavalt. Alustasime 2018. aasta alguses ja lihtsalt arendasime seda suunda entusiastlikult. Müük on just alanud ja meil on see protsess.
Dmitri:
Kas juhtub, et ettevõte lubab teha selliseid asju nagu Google – ühel vabal päeval nädalas? Kas teil on selline suund?
Aleksander:
Teadustööga samal ajal tegelesime ka äriprobleemidega, seega on kõik meie mikroteenused lahendused äriprobleemidele. Alles alguses ehitasime mikroteenuseid, mis katsid väikese osa tellijabaasist ja nüüd oleme kohal peaaegu kõigis lipulaevatoodetes.
Ja materiaalne mõju on juba selge – meid võib juba lugeda, hinnata toodete turuletuleku kiirust ja saamata jäänud tulu, kui oleksime vana rada järginud. Sellele me juhtumit ehitame.
Mikroteenused: hüpe või vajadus?
Dmitri:
Numbrid on numbrid. Ja tulu või säästetud raha on väga oluline. Mis siis, kui vaatate teisele poole? Tundub, et mikroteenused on trend, haip ja paljud ettevõtted kuritarvitavad seda? Kui selgelt teete vahet sellel, mida teete ja mida ei tõlgi mikroteenusteks? Kui pärand praegu, kas teil on pärand veel 5 aasta pärast? Kui vanaks saavad M.Video-Eldorados ja MegaFonis töötavad infosüsteemid 5 aasta pärast? Kas tuleb kümme, viisteist aastat vanad infosüsteemid või uus põlvkond? Kuidas te seda näete?
Sergei:
Mulle tundub, et väga kaugele mõelda on raske. Kui vaatame tagasi, siis kes arvas, et tehnoloogiaturg niimoodi areneb, sealhulgas masinõpe ja kasutaja näo järgi tuvastamine? Aga kui vaadata lähiaastaid, siis mulle tundub, et põhisüsteemid, ettevõtete ERP-klassi süsteemid - need on juba päris kaua töötanud.
Meie ettevõtted on kollektiivselt 25 aastat vanad ja klassikaline ERP on süsteemimaastikul väga sügaval. Selge on see, et võtame sealt mingid jupid välja ja üritame neid mikroteenusteks koondada, aga tuum jääb alles. Mul on praegu raske ette kujutada, et vahetame kõik seal olevad põhisüsteemid välja ja liigume kiiresti uute süsteemide teisele, helgemale poolele.
Olen selle pooldaja, et kõik, mis on kliendile ja tarbijale lähemal, on seal, kus on suurim ärikasu ja väärtus, kus on kohanemisvõime ja keskendumine kiirusele, muutustele, "proovi, tühista, taaskasuta, tee midagi teisiti" vaja – seal muutub maastik. Ja karbitooted ei sobi sinna eriti hästi. Vähemalt me ei näe seda. Seal on vaja kõige lihtsamaid ja lihtsamaid lahendusi.
Näeme seda arengut:
- põhilised infosüsteemid (enamasti back office);
- keskmised kihid mikroteenuste kujul ühendavad tuuma, koondavad, loovad vahemälu jne;
- eesliinisüsteemid on suunatud tarbijale;
- integratsioonikiht, mis on üldiselt integreeritud turgude, muude süsteemide ja ökosüsteemidega. See kiht on võimalikult kerge, lihtne ja sisaldab minimaalselt äriloogikat.
Kuid samas toetan vanade põhimõtete edasist kasutamist, kui neid asjakohaselt kasutatakse.
Oletame, et teil on klassikaline ettevõttesüsteem. See asub ühe müüja maastikul ja koosneb kahest moodulist, mis töötavad omavahel. Samuti on olemas standardne integreerimisliides. Miks seda ümber teha ja mikroteenus sinna tuua?
Aga kui tagakontoris on 5 moodulit, millest kogutakse infokillud äriprotsessi, mida siis 8-10 eesliinisüsteemi kasutavad, on kasu kohe märgatav. Võtate viiest back-office süsteemist ja loote teenuse, isoleeritud, mis on keskendunud äriprotsessile. Muutke teenus tehnoloogiliselt arenenuks – nii, et see salvestaks teavet vahemällu ja oleks tõrketaluv ning töötaks ka dokumentide või äriüksustega. Ja integreerite selle ühe põhimõtte kohaselt kõigi esiliini toodetega. Nad tühistasid eesliinitoote – lülitasid integratsiooni lihtsalt välja. Homme pead kirjutama mobiilirakenduse või tegema väikese veebilehe ja panema funktsionaalsusesse ainult ühe osa – kõik on lihtne: panid selle kokku nagu konstruktor. Ma näen selles suunas rohkem arengut – vähemalt meie riigis.
Aleksander:
Sergey kirjeldas meie lähenemist täielikult, aitäh. Ütlen lihtsalt, kuhu me kindlasti ei lähe – põhiosa juurde, veebiarvelduse teema juurde. See tähendab, et reiting ja tasustamine jäävad tegelikult “suureks” peksjaks, mis kannab raha usaldusväärselt maha. Ja seda süsteemi sertifitseerivad ka edaspidi meie reguleerivad asutused. Kõik muu, mis klientide poole vaatab, on loomulikult mikroteenused.
Dmitri:
Siin on sertifitseerimine üks lugu. Ilmselt rohkem toetust. Kui kulutate toele vähe või süsteem ei vaja tuge ega muudatusi, on parem seda mitte puudutada. Mõistlik kompromiss.
Kuidas arendada usaldusväärseid mikroteenuseid
Dmitri:
Hästi. Aga olen ikkagi huvitatud. Nüüd räägite edulugu: kõik oli korras, läksime üle mikroteenustele, kaitsesime idee ärile ja kõik õnnestus. Aga ma olen kuulnud ka teisi jutte.
Paar aastat tagasi pani Šveitsi ettevõte, kes oli kaks aastat investeerinud pankade uue mikroteenuste platvormi väljatöötamisse, projekti lõpuks kinni. Täiesti kokku varisenud. Kulutati palju miljoneid Šveitsi franke ja lõpuks läks meeskond laiali – see ei õnnestunud.
Kas teil on sarnaseid lugusid olnud? Kas oli või on raskusi? Näiteks mikroteenuste ja monitooringu pidamine valmistab peavalu ka ettevõtte operatiivtegevuses. Lõppude lõpuks suureneb komponentide arv kümneid kordi. Kuidas te seda näete, kas siin on olnud ebaõnnestunud investeeringute näiteid? Ja mida saate inimestele soovitada, et neil selliseid probleeme ei tekiks?
Aleksander:
Ebaõnnestunud näidete hulka kuulusid ettevõtted, kes muutsid prioriteete ja tühistasid projekte. Heas valmisoleku staadiumis (tegelikult on MVP valmis) ütles ettevõte: "Meil on uued prioriteedid, liigume teise projekti juurde ja sulgeme selle."
Meil ei olnud mikroteenustega globaalseid tõrkeid. Magame rahulikult, meil on ööpäevaringne valve, mis teenindab kogu BSS-i [äri tugisüsteemi].
Ja veel üks asi - rendime välja mikroteenuseid vastavalt karbis kehtivatele reeglitele. Edu võti on see, et esiteks tuleb kokku panna meeskond, kes valmistaks mikroteenuse täielikult tootmiseks ette. Areng ise on tinglikult 40%. Ülejäänud on analüüs, DevSecOpsi metoodika, õiged integratsioonid ja õige arhitektuur. Pöörame erilist tähelepanu turvaliste rakenduste ehitamise põhimõtetele. Infoturbe esindajad osalevad igas projektis nii arhitektuuri planeerimise etapis kui ka teostusprotsessis. Nad haldavad ka turvaaukude koodi analüüsimise süsteeme.
Oletame, et võtame kasutusele oma kodakondsuseta teenused – meil on need Kubernetesis. See võimaldab kõigil teenuste automaatse skaleerimise ja automaatse tõstmise tõttu rahulikult magada ning töövahetus tõstab vahejuhtumeid.
Kogu meie mikroteenuste eksisteerimise jooksul on meie ridadesse jõudnud vaid üks-kaks intsidenti. Nüüd pole operatsiooniga probleeme. Meil pole muidugi mitte 200, vaid umbes 50 mikroteenust, kuid neid kasutatakse lipulaevatoodetes. Kui need ebaõnnestuksid, oleksime esimesed, kes sellest teada saavad.
Mikroteenused ja HR
Sergei:
Nõustun kolleegiga toetusele ülemineku osas - et töö tuleb korrektselt korraldada. Kuid ma räägin teile probleemidest, mis loomulikult eksisteerivad.
Esiteks on tehnoloogia uus. See on heas mõttes hype ja spetsialisti leidmine, kes seda mõistaks ja oskaks luua, on suur väljakutse. Konkurents ressursside pärast on meeletu, nii et eksperdid on kulda väärt.
Teiseks tuleb teatud maastike loomise ja teenuste arvu kasvuga pidevalt lahendada taaskasutuse probleem. Nagu arendajatele meeldib: "Kirjutame siia nüüd palju huvitavat..." Selle tõttu süsteem kasvab ja kaotab oma efektiivsuse raha, omamiskulude jms osas. See tähendab, et süsteemiarhitektuuri on vaja lisada korduvkasutamine, lisada see tegevuskavasse teenuste juurutamiseks ja pärandi ülekandmiseks uuele arhitektuurile.
Teine probleem – kuigi see on omal moel hea – on sisemine konkurents. "Oh, siia on ilmunud uued moodsad tüübid, nad räägivad uut keelt." Inimesed on muidugi erinevad. On neid, kes on harjunud Java keeles kirjutama, ja neid, kes kirjutavad ja kasutavad Dockerit ja Kubernetest. Need on täiesti erinevad inimesed, nad räägivad erinevalt, kasutavad erinevaid termineid ja mõnikord ei mõista üksteist. Probleemiks on selles mõttes ka oskus või oskamatus jagada praktikat, teadmiste jagamist.
Noh, ressursside skaleerimine. „Tore, lähme! Ja nüüd tahame kiiremini, rohkem. Mida, sa ei saa? Kas aastaga pole võimalik tarnida kaks korda rohkem? Ja miks?" Sellised kasvuvalud on ilmselt paljude asjade, paljude lähenemiste standardsed ja neid on tunda.
Seoses jälgimisega. Mulle tundub, et teenused või tööstuslikud seiretööriistad juba õpivad või on võimelised töötama nii Dockeri kui ka Kubernetesega erinevas, mittestandardses režiimis. Et näiteks ei jääks kokku 500 Java-masinat, mille all see kõik töötab, nimelt agregeerub. Kuid neil toodetel puudub endiselt küpsus; nad peavad selle läbima. Teema on tõesti uus, areneb edasi.
Dmitri:
Jah, väga huvitav. Ja see kehtib HR kohta. Võib-olla on teie personaliprotsess ja personalibränd selle 3 aasta jooksul pisut muutunud. Hakkasite värbama teisi erineva pädevusega inimesi. Ja ilmselt on nii plusse kui miinuseid. Varem olid plokiahel ja andmeteadus pähe ning nende spetsialistid olid väärt miljoneid. Nüüd kulud langevad, turg on küllastunud ja sarnane trend on ka mikroteenustes.
Sergei:
Jah, absoluutselt.
Aleksander:
HR esitab küsimuse: "Kus on teie roosa ükssarvik tausta- ja esiosa vahel?" HR ei saa aru, mis on mikroteenus. Rääkisime neile saladuse ja ütlesime, et taustaprogramm tegi kõik ja ükssarvikut pole olemas. Kuid HR muutub, õpib kiiresti ja värbab inimesi, kellel on IT-alased algteadmised.
Mikroteenuste areng
Dmitri:
Kui vaatate sihtarhitektuuri, näevad mikroteenused välja nagu selline koletis. Teie teekond kestis mitu aastat. Teistel on aasta, teistel kolm aastat. Kas nägite ette kõiki probleeme, sihtarhitektuuri, kas midagi muutus? Näiteks mikroteenuste puhul ilmuvad nüüd uuesti lüüsid ja teenindusvõrgud. Kas kasutasite neid alguses või muutsite arhitektuuri ennast? Kas teil on selliseid väljakutseid?
Sergei:
Oleme juba mitu sideprotokolli ümber kirjutanud. Algul oli üks protokoll, nüüd läksime teisele üle. Suurendame ohutust ja töökindlust. Alustasime ettevõtete tehnoloogiatega – Oracle, Web Logic. Nüüd eemaldume mikroteenustes tehnoloogilistest ettevõtete toodetest ja liigume avatud lähtekoodiga või täiesti avatud tehnoloogiatele. Loobume andmebaasidest ja liigume selle juurde, mis selles mudelis meie jaoks tõhusamalt töötab. Me ei vaja enam Oracle'i tehnoloogiaid.
Alustasime lihtsalt teenusena, mõtlemata, kui palju vahemälu vajame, mida teeme siis, kui mikroteenusega ühendust pole, aga andmeid oli vaja jne. Nüüd arendame platvormi, et arhitektuuri saaks kirjeldada mitte teenuste keeles ja ärikeeles viige äriloogika järgmisele tasemele, kui hakkame sõnadega rääkima. Nüüd oleme õppinud rääkima tähtedega ja järgmine tase on see, kui teenused koondatakse mingisse agregaadi, kui see on juba sõna - näiteks terve tootekaart. See on kokku pandud mikroteenustest, kuid see on sellele peale ehitatud API.
Ohutus on väga oluline. Niipea, kui hakkate olema juurdepääsetav ja teil on teenus, mille kaudu saate palju huvitavat, ja väga kiiresti, sekundi murdosa jooksul, tekib soov saada see mitte kõige turvalisemal viisil. Sellest vabanemiseks pidime muutma lähenemisviise testimisele ja jälgimisele. Pidime muutma meeskonda, tarnehaldusstruktuuri, CI/CD-d.
See on areng – nagu telefonidega, ainult palju kiiremini: algul olid nupuvajutusega telefonid, siis ilmusid nutitelefonid. Nad kirjutasid ja kujundasid toote ümber, kuna turul oli teistsugune vajadus. Nii me areneme: esimene klass, kümnes klass, töö.
Iteratiivselt pannakse aastas midagi paika tehnoloogia poolelt, midagi muud mahajäämuse ja vajaduste seisukohalt. Me ühendame ühe asja teisega. Meeskond kulutab 20% tehnilisele võlale ja meeskonna tehnilisele toele, 80% äriüksusele. Ja me mõistame, miks me seda teeme, miks me teeme neid tehnoloogilisi täiustusi ja milleni need kaasa toovad. Nagu see.
Dmitri:
Lahe. Mis on MegaFonis?
Aleksander:
Peamine väljakutse mikroteenuste juurde jõudes oli mitte langeda kaosesse. MegaFoni arhitektuuribüroo liitus meiega kohe, sai isegi algatajaks ja veduriks – nüüd on meil väga tugev arhitektuur. Tema ülesandeks oli mõista, millise sihtmudeli poole me läheme ja milliseid tehnoloogiaid on vaja piloteerida. Arhitektuuriga viisime need piloodid ise läbi.
Järgmine küsimus oli: "Kuidas siis seda kõike ära kasutada?" Ja veel üks: "Kuidas tagada läbipaistev interaktsioon mikroteenuste vahel?" Teenindusvõrk aitas meil viimasele küsimusele vastata. Pilootasime Istiot ja tulemused meeldisid. Nüüd oleme tootmistsoonidesse levimise etapis. Suhtume positiivselt kõikidesse väljakutsetesse – sellesse, et peame pidevalt stäkki vahetama, midagi uut õppima. Oleme huvitatud arendamisest, mitte vanade lahenduste ekspluateerimisest.
Dmitri:
Kuldsed sõnad! Sellised väljakutsed hoiavad meeskonda ja ettevõtet püsti ning loovad tulevikku. GDPR lõi juhtivad andmekaitseametnikud ja praegused väljakutsed loovad mikroteenuste ja arhitektuuriametnikud. Ja see meeldib.
Arutasime palju. Peaasi, et mikroteenuste hea disain ja arhitektuur ise võimaldab vältida paljusid vigu. Loomulikult on protsess iteratiivne ja evolutsiooniline, kuid see on tulevik.
Aitäh kõigile osalejatele, aitäh Sergeile ja Aleksandrile!
Küsimused publikult
Küsimus publikult (1):
Sergey, kuidas on IT-juhtimine teie ettevõttes muutunud? Ma saan aru, et kui on olemas suur virn mitut süsteemi, siis selle haldamine on üsna selge ja loogiline protsess. Kuidas te IT-komponendi halduse ümber ehitasite pärast seda, kui nii lühikese ajaga integreeriti väga palju mikroteenuseid?
Sergei:
Nõustun kolleegiga, et arhitektuur on muutuste käivitajana väga oluline. Alustasime arhitektuuriosakonna loomisest. Arhitektid on samaaegselt nii funktsionaalsuse jaotuse kui ka maastikul ilmumise nõuete omanikud. Seega tegutsevad nad ka nende muudatuste koordinaatoritena. Selle tulemusena tehti CI/CD platvormi loomisel konkreetses tarneprotsessis konkreetseid muudatusi.
Kuid standardit, arenduse põhiprintsiipe, ärianalüüsi, testimist ja arendust pole tühistatud. Lisasime lihtsalt kiirust. Varem võttis tsükkel nii palju aega, testkeskkondadesse installimine võttis palju rohkem aega. Nüüd näeb äri sellest kasu ja ütleb: "Miks me ei võiks sama teha mujal?"
See on heas mõttes nagu vaktsiinisüst, mis näitas: saate seda teha nii, kuid saate seda teha ka teisiti. Muidugi on probleem personalis, pädevustes, teadmistes, vastupanus.
Küsimus publikult (2):
Mikroteenuste arhitektuuri kriitikud ütlevad, et testimine ja arendamine on keeruline. See on loogiline, kui asjad lähevad keeruliseks. Milliste väljakutsetega teie meeskond silmitsi seisis ja kuidas neist üle saite? Küsimus kõigile.
Aleksander:
Mikroteenustelt platvormile üleminekul on raskusi, kuid need on lahendatavad.
Näiteks valmistame toodet, mis koosneb 5-7 mikroteenusest. Peame pakkuma integratsiooniteste kogu mikroteenuste virna ulatuses, et anda roheline tuli põhiharule liikumiseks. See ülesanne ei olnud meie jaoks uus: olime seda BSS-is juba pikka aega teinud, kui müüja varustas meid juba tarnitud lahendustega.
Ja meie probleem on ainult väikeses meeskonnas. Ühe tingimusliku toote jaoks on vaja ühte kvaliteedikontrolli inseneri. Ja nii tarnime toote, mis koosneb 5-7 mikroteenusest, millest 2-3 saavad arendada kolmandad osapooled. Näiteks on meil toode, mille arendamisel osalevad meie arveldussüsteemi tarnija, Mail.ru Group ja MegaFon R&D. Peame selle enne tootmisse saatmist testidega katma. Kvaliteedikontrolli insener on selle toote kallal töötanud poolteist kuud ja ülejäänud meeskond jääb tema toetuseta.
Seda keerukust põhjustab ainult skaleerimine. Me mõistame, et mikroteenused ei saa eksisteerida vaakumis; absoluutset isolatsiooni ei eksisteeri. Ühe teenuse muutmisel püüame alati API lepingut säilitada. Kui kapoti all midagi muutub, jääb esihooldus alles. Kui muudatused saavad saatuslikuks, toimub mingi arhitektuurne transformatsioon ja minnakse üle hoopis teisele andmemetamudelile, mis on täiesti ühildamatu – alles siis räägime v2 service API spetsifikatsiooni ilmumisest. Toetame samaaegselt esimest ja teist versiooni ning pärast seda, kui kõik tarbijad lülituvad teisele versioonile, sulgeme lihtsalt esimese.
Sergei:
Ma tahan lisada. Tüsistuste osas olen täiesti nõus – neid juhtub. Maastik muutub keerulisemaks ja üldkulud suurenevad, eriti testimise eest. Kuidas sellega toime tulla: lülituge automatiseeritud testimisele. Jah, peate lisaks investeerima autotestide ja ühikutestide kirjutamisse. Et arendajad ei saaks ilma testi läbimata pühenduda, ei saanud nad koodi muuta. Et isegi nupp ei töötaks ilma automaattesti, ühiktestita.
Oluline on säilitada eelmine funktsionaalsus ja see on lisakulu. Kui kirjutate tehnoloogia ümber teisele protokollile, siis kirjutate seda ümber, kuni sulgete kõik täielikult.
Mõnikord ei tee me sihilikult täistestimist, sest me ei taha arendust peatada, kuigi meil on ka üks asi teise järel. Maastik on väga suur, keeruline, süsteeme on palju. Mõnikord on see lihtsalt tüngadest – jah, kui alandate ohutusvaru, ilmneb rohkem riske. Kuid samal ajal vabastate varu.
Aleksander:
Jah, automaattestid ja ühikutestid võimaldavad teil luua kvaliteetse teenuse. Oleme torujuhtme poolt, mida ei saa läbida ilma üksuse- ja integratsioonitestideta. Tihti peame tõmbama emulaatoreid ja kommertssüsteeme testtsoonidesse ja arenduskeskkondadesse, sest kõiki süsteeme ei saa testtsoonidesse paigutada. Pealegi ei saa need lihtsalt märjaks – genereerime süsteemilt täieõigusliku vastuse. See on mikroteenustega töötamise tõsine osa ja me ka investeerime sellesse. Ilma selleta tekib kaos.
Küsimus publikult (3):
Minu arusaamist mööda kasvasid mikroteenused algselt välja eraldi meeskonnast ja on nüüd selles mudelis olemas. Mis on selle plussid ja miinused?
Meil on just sarnane lugu: tekkis omamoodi mikroteenuste tehas. Nüüd oleme kontseptuaalselt jõudnud selleni, et laiendame seda lähenemist tootmisele voogude ja süsteemide kaupa. Teisisõnu, me eemaldume mikroteenuste, mikroteenuste mudelite tsentraliseeritud arendamisest ja läheneme süsteemidele.
Sellest lähtuvalt läheb meie tegevus ka süsteemidele ehk detsentraliseerime selle teema. Milline on teie lähenemine ja mis on teie sihtlugu?
Aleksander:
Jätsite nime „mikroteenuste tehas” otse välja – me tahame ka skaleerida. Esiteks on meil nüüd tõesti üks meeskond. Soovime pakkuda kõikidele MegaFoni arendusmeeskondadele võimalust töötada ühises ökosüsteemis. Me ei taha täielikult üle võtta kogu arendusfunktsiooni, mis meil praegu on. Kohalik ülesanne on skaleerimine, globaalne ülesanne on viia arendus kõigisse mikroteenuste kihi meeskondadesse.
Sergei:
Ma räägin teile tee, mille oleme käinud. Alustasime tõesti ühe meeskonnana töötamist, kuid nüüd pole me üksi. Olen järgmise pooldaja: protsessil peab olema omanik. Keegi peab mikroteenuste arendusprotsessi mõistma, juhtima, kontrollima ja üles ehitama. Ta peab omama ressursse ja tegelema ressursside haldamisega.
Need ressursid, kes tunnevad tehnoloogiaid, spetsiifikat ja mõistavad, kuidas mikroteenuseid luua, võivad asuda tootemeeskondades. Meil on segu, kus mobiilirakendust tegevas tootemeeskonnas on inimesed mikroteenuse platvormilt. Nad on olemas, kuid töötavad vastavalt mikroteenuste platvormi haldusosakonna protsessile koos oma arendusjuhiga. Selle divisjoni sees on eraldi meeskond, mis tegeleb tehnoloogiaga. See tähendab, et me segame omavahel ühise ressursside kogumi ja jagame need ära, andes need meeskondadele.
Samal ajal jääb protsess üldiseks, kontrollituks, kulgeb üldiste tehnoloogiliste põhimõtete järgi, ühikutestimisega ja nii edasi - kõik, mis on peale ehitatud. Tootepõhise lähenemisviisi erinevatest osakondadest kogutud ressursside kujul võivad olla veerud.
Aleksander:
Sergey, sa oled tegelikult protsessi omanik, eks? Kas ülesannete mahajäämus on jagatud? Kes vastutab selle levitamise eest?
Sergei:
Vaata: siin on jälle segu. On mahajäämus, mis moodustub tehnoloogiliste täiustuste põhjal – see on üks lugu. On mahajäämus, mis vormistatakse projektidest, ja on mahajäämus toodetest. Kuid iga teenusetoote tutvustamise või selle teenuse loomise järjestuse töötab välja tootespetsialist. Ta ei ole IT-direktoraadis, ta eemaldati sealt spetsiaalselt. Aga minu inimesed töötavad kindlasti sama protsessi järgi.
Erinevate suundade mahajäämuse – muudatuste mahajäämuse – omanikuks saavad erinevad inimesed. Tehnoloogiliste teenuste ühendamine, nende korralduspõhimõte - kõik see saab olema IT-s. Mul on ka platvorm ja ressursid. Üleval on see, mis puudutab mahajäämust ja funktsionaalseid muudatusi ning selles mõttes arhitektuuri.
Oletame, et ettevõte ütleb: "Me tahame seda funktsiooni, tahame luua uue toote – laenu uuesti teha." Vastame: "Jah, me teeme selle uuesti." Arhitektid ütlevad: "Mõtleme: kuhu laenu mikroteenuseid kirjutame ja kuidas seda teeme?" Seejärel jagame selle projektideks, toodeteks või tehnoloogiavirnaks, paneme meeskondadesse ja rakendame. Kas olete loonud toote ettevõttesiseselt ja otsustanud kasutada selles tootes mikroteenuseid? Me ütleme: "Nüüd peavad meie pärandsüsteemid või eesliinisüsteemid nendele mikroteenustele üle minema." Arhitektid ütlevad: "Seega: tehnoloogilises mahajäämuses esiliini toodete sees - üleminek mikroteenustele. Mine". Ja tootespetsialistid või ettevõtete omanikud saavad aru, kui palju võimsust on eraldatud, millal seda tehakse ja miks.
Arutelu lõpp, aga mitte kõik
Korraldati mailto:CLOUD konverents .
Teeme ka muid üritusi - nt. @Kubernetes Meetup, kus otsime alati suurepäraseid kõlareid:
- Jälgi @Kubernetes ja teisi @Meetup uudiseid meie Telegrami kanalis
- Kas olete huvitatud mõnel @Meetupsil esinemisest? Jäta taotlus
Allikas: www.habr.com