Më 25 Prill, ne në Mail.ru Group mbajtëm një konferencë rreth reve dhe përreth - . Disa pika kryesore:
- Kryesor — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center dhe Yandex.Cloud folën për specifikat e tregut tonë cloud dhe shërbimet e tyre;
- Kolegët nga Bitrix24 treguan se si ata ;
- Leroy Merlin, Otkritie, Burger King dhe Schneider Electric dhanë interesa — çfarë detyrash vendos biznesi i tyre për IT dhe cilat teknologji, duke përfshirë ato cloud, i shohin si më premtueset.
Mund të shikoni të gjitha videot nga konferenca mailto:CLOUD , dhe këtu mund të lexoni se si shkoi diskutimi për mikroshërbimet. Alexander Deulin, kreu i qendrës së kërkimit dhe zhvillimit të sistemeve të biznesit MegaFon dhe Sergey Sergeev, drejtor i teknologjisë së informacionit të grupit M.Video-Eldorado, ndanë rastet e tyre të suksesshme për të hequr qafe monolitet. Ne diskutuam gjithashtu çështje të lidhura me strategjinë e TI-së, proceset dhe madje edhe HR.
Panelistët
- Sergej Sergeev, CIO i Grupit "M.Video-Eldorado";
- Alexander Deulin, shef i qendrës për kërkimin dhe zhvillimin e sistemeve të biznesit MegaFon;
- Moderator - Dmitry Lazarenko, Shef i drejtimit të PaaS Mail.ru Cloud Solutions.
Pas fjalimit të Alexander Deulin atij i bashkohet për diskutim Sergej Sergeev nga M.Video-Eldorado dhe moderatori i diskutimit Dmitry Lazarenko, Mail.ru Cloud Solutions.
Më poshtë kemi përgatitur një transkript të diskutimit për ju, por mund të shikoni edhe videon:
Kalimi në mikroshërbime është një përgjigje ndaj nevojave të tregut
Dmitri:
A keni pasur ndonjë përvojë të suksesshme migrimi në mikroshërbime? Dhe në përgjithësi: ku e shihni përfitimin më të madh të biznesit nga përdorimi i mikroshërbimeve apo kalimi nga monolit në mikroshërbime?
Sergey:
Tashmë kemi kaluar disi në kalimin në mikroshërbime dhe e kemi përdorur këtë qasje për më shumë se tre vjet. Nevoja e parë që justifikonte nevojën për mikroshërbime ishte integrimi i pafund i produkteve të ndryshme të përparme me zyrën e pasme. Dhe çdo herë ne detyroheshim të bënim integrim dhe zhvillim shtesë, duke zbatuar rregullat tona për funksionimin e këtij apo atij shërbimi.
Në një moment, ne kuptuam se duhej të shpejtonim funksionimin e sistemeve tona dhe daljen e funksionalitetit. Në atë moment, koncepte të tilla si mikroshërbimet dhe një qasje mikroservice ekzistonin tashmë në treg, dhe ne vendosëm ta provonim. Kjo filloi në vitin 2016. Më pas u shtrua platforma dhe 10 shërbimet e para u zbatuan nga një ekip i veçantë.
Një nga shërbimet e para, më i ngarkuari, ishte shërbimi i llogaritjes së çmimit. Sa herë që vini në ndonjë kanal, në grupin e kompanive M.Video-Eldorado, qoftë faqe interneti apo dyqan me pakicë, zgjidhni një produkt atje, shikoni çmimin në uebsajt ose në "Shporta", kostoja është automatikisht. llogaritur nga një shërbim. Pse është e nevojshme kjo: para kësaj, çdo sistem kishte parimet e veta për të punuar me promovime - me zbritje dhe kështu me radhë. Zyra jonë e pasme merret me çmimet; funksionaliteti i zbritjes zbatohet në një sistem tjetër. Kjo duhej të centralizohej dhe të krijohej një shërbim unik dhe i ndashëm në formën e një procesi biznesi që do të na lejonte ta zbatonim këtë. Pak a shumë kështu filluam.
Vlera e rezultateve të para ishte shumë e madhe. Së pari, ne ishim në gjendje të krijonim entitete të ndashme që na lejojnë të punojmë veçmas dhe në mënyrë të përmbledhur. Së dyti, ne kemi ulur koston e pronësisë në drejtim të integrimit me më shumë sisteme.
Gjatë tre viteve të fundit, ne kemi shtuar tre sisteme të vijës së parë. Ishte e vështirë t'i ruante ato me të njëjtën sasi burimesh që kompania mund të përballonte. Prandaj, lindi detyra për të kërkuar pika të reja shitjeje, duke iu përgjigjur tregut për nga shpejtësia, për sa i përket kostove të brendshme dhe efikasitetit.
Si të matet suksesi i migrimit në mikroshërbime
Dmitri:
Si përcaktohet suksesi në migrimin në mikroshërbime? Cila ishte “më parë” në secilën kompani? Çfarë metrike keni përdorur për të përcaktuar suksesin e tranzicionit dhe kush e përcaktoi atë në të vërtetë?
Sergey:
Para së gjithash, ai lindi brenda IT-së si një mundësi - "zhbllokimin" e aftësive të reja. Ne kishim nevojë të bënim gjithçka më shpejt për relativisht të njëjtat para, duke iu përgjigjur sfidave të tregut. Tani suksesi shprehet në numrin e shërbimeve të ripërdorura nga sisteme të ndryshme, unifikimin e proceseve ndërmjet tyre. Tani është, por në atë moment ishte një mundësi për të krijuar një platformë dhe për të konfirmuar hipotezën se mund ta bëjmë këtë, do të japë efekt dhe do të llogarisë rastin e biznesit.
Aleksandri:
Suksesi është më tepër një ndjenjë e brendshme. Biznesi gjithmonë dëshiron më shumë, dhe thellësia e ngarkesës sonë është dëshmi e suksesit. Kështu më duket mua.
Sergey:
Po unë pajtohem. Në tre vjet, ne kemi tashmë më shumë se dyqind shërbime dhe të prapambetura. Nevoja për burime brenda ekipit po rritet vetëm - me 30% në vit. Kjo po ndodh sepse njerëzit mendonin: është më shpejt, është ndryshe, ka teknologji të ndryshme, e gjithë kjo po zhvillohet.
Mikroshërbimet do të vijnë, por thelbi do të mbetet
Dmitri:
Është si një proces i pafund ku investoni në zhvillim. A ka përfunduar tashmë apo jo kalimi në mikroshërbime për biznesin?
Sergey:
Është shumë e lehtë të përgjigjesh. Çfarë mendoni: zëvendësimi i telefonave është një proces i pafund? Ne vetë blejmë telefona çdo vit. Dhe ja ku është: për sa kohë që ka nevojë për shpejtësi, për përshtatje me tregun, do të kërkohen disa ndryshime. Kjo nuk do të thotë që ne i braktisim gjërat standarde.
Por ne nuk mund të mbulojmë dhe ribëjmë gjithçka menjëherë. Ne kemi trashëgimi, shërbime standarde të integrimit që ekzistonin më parë: autobusët e ndërmarrjeve dhe kështu me radhë. Por ka një prapambetje, dhe gjithashtu ka nevojë. Numri i aplikacioneve celulare dhe funksionaliteti i tyre po rritet. Në të njëjtën kohë, askush nuk thotë se do t'ju jepen 30% më shumë para. Kjo do të thotë, ka gjithmonë nevoja nga njëra anë dhe një kërkim për efikasitet nga ana tjetër.
Dmitri:
Jeta është në gjendje të mirë. (Qesh)
Aleksandri:
Në përgjithësi, po. Ne nuk kemi qasje revolucionare për të hequr pjesën thelbësore nga peizazhi. Puna sistematike është duke u zhvilluar për të zbërthyer sistemet në mënyrë që ato të jenë më konsistente me arkitekturën e mikroshërbimeve, për të zvogëluar ndikimin e sistemeve mbi njëri-tjetrin.
Por ne planifikojmë të mbajmë pjesën thelbësore, pasi në peizazhin e operatorit do të ketë gjithmonë disa platforma që ne blejmë. Përsëri, ne kemi nevojë për një ekuilibër të shëndetshëm: nuk duhet të nxitojmë për të prerë thelbin. Ne i vendosim sistemet krah për krah, dhe tani rezulton se ne jemi tashmë në krye të shumë pjesëve thelbësore. Më tej, duke zhvilluar funksionalitetin, ne krijojmë përfaqësimet e nevojshme për të gjitha kanalet që punojnë me shërbimet tona të komunikimit.
Si të shisni mikroshërbime për bizneset
Dmitri:
Unë jam gjithashtu i interesuar - për ata që nuk kanë kaluar, por po planifikojnë: sa e lehtë ishte t'ia shisje këtë ide biznesit dhe a ishte një aventurë, një projekt investimi? Apo ishte një strategji e vetëdijshme: tani po shkojmë në mikroshërbime dhe kaq, asgjë nuk do të na ndalojë. Si ishte për ju?
Sergey:
Ne nuk po shisnim një qasje, por një përfitim biznesi. Kishte një problem në biznes dhe ne u përpoqëm ta zgjidhnim. Në atë moment, u shpreh në faktin se kanale të ndryshme përdorën parime të ndryshme për llogaritjen e çmimeve - veçmas për promovime, për promovime, etj. Ishte e vështirë për t'u mirëmbajtur, ndodhën gabime dhe ne dëgjuam ankesat e klientëve. Domethënë, ne po shisnim një zgjidhje për një problem, por erdhëm me faktin se na duheshin para për të krijuar një platformë. Dhe ata treguan një rast biznesi duke përdorur shembullin e fazës së parë të investimit: si do të vazhdojmë ta rikuperojmë atë dhe çfarë do të na lejojë kjo të bëjmë.
Dmitri:
E keni regjistruar disi kohën e fazës së parë?
Sergey:
Po sigurisht. Ne ndamë 6 muaj për të krijuar bërthamën si platformë dhe për të testuar pilotin. Gjatë kësaj kohe, ne u përpoqëm të krijonim një platformë mbi të cilën të bënim patinazh pilotin. Pastaj hipoteza u konfirmua, dhe meqenëse funksionon, do të thotë se mund të vazhdojmë. Ata filluan të përsëriten dhe e forcuan ekipin - ata e zhvendosën atë në një divizion të veçantë që bën pikërisht këtë.
Më pas vjen puna sistematike bazuar në nevojat e biznesit, mundësitë, disponueshmërinë e burimeve dhe gjithçka që është aktualisht në punë.
Dmitri:
NE RREGULL. Aleksandër, çfarë thua?
Aleksandri:
Mikroshërbimet tona lindën nga "shkuma e detit" - për shkak të kursimit të burimeve, për shkak të disa mbetjeve në formën e kapacitetit të serverit dhe rishpërndarjes së forcave brenda ekipit. Fillimisht, ne nuk ia shitëm këtë projekt biznesit. Ky ishte një projekt ku ne të dy hulumtuam dhe zhvilluam në përputhje me rrethanat. Ne filluam në fillim të 2018 dhe thjesht e zhvilluam këtë fushë me entuziazëm. Shitjet sapo kanë filluar dhe ne jemi në proces.
Dmitri:
A ndodh që një biznes të lejon të bësh gjëra të tilla si Google - në një ditë të lirë në javë? Keni një drejtim të tillë?
Aleksandri:
Në të njëjtën kohë me kërkimin, ne u morëm edhe me problemet e biznesit, kështu që të gjitha mikroshërbimet tona janë zgjidhje për problemet e biznesit. Vetëm në fillim ndërtuam mikroshërbime që mbulonin një pjesë të vogël të bazës së abonentëve dhe tani jemi prezent në pothuajse të gjitha produktet kryesore.
Dhe ndikimi material është tashmë i qartë - ne tashmë mund të numërohemi, shpejtësia e lançimit të produkteve dhe të ardhurat e humbura mund të vlerësohen nëse do të kishim ndjekur rrugën e vjetër. Kjo është ajo mbi të cilën po e ndërtojmë çështjen.
Mikroshërbimet: zhurmë apo domosdoshmëri?
Dmitri:
Numrat janë numra. Dhe të ardhurat ose paratë e kursyera janë shumë të rëndësishme. Po sikur të shikoni në anën tjetër? Duket se mikroshërbimet janë një trend, një bujë dhe shumë kompani po e keqpërdorin atë? Sa qartë e bëni dallimin midis asaj që bëni dhe asaj që nuk e përktheni në mikroshërbime? Nëse trashëgimi tani, a do të keni akoma trashëgimi në 5 vjet? Sa do të jetë mosha e sistemeve të informacionit që punojnë në M.Video-Eldorado dhe MegaFon pas 5 vitesh? A do të ketë sisteme informacioni dhjetëvjeçare, pesëmbëdhjetëvjeçare apo do të jetë një gjeneratë e re? Si e shihni këtë?
Sergey:
Më duket se është e vështirë të mendosh shumë larg. Nëse shikojmë prapa, kush e imagjinoi që tregu i teknologjisë do të zhvillohej në këtë mënyrë, duke përfshirë mësimin e makinerive dhe identifikimin e përdoruesit me fytyrë? Por nëse shikoni vitet e ardhshme, më duket se sistemet thelbësore, sistemet e klasës ERP të ndërmarrjeve në kompani - ato kanë funksionuar për një kohë mjaft të gjatë.
Kompanitë tona janë së bashku 25 vjeç, me ERP klasike shumë të thellë në peizazhin e sistemeve. Është e qartë se ne po nxjerrim disa pjesë që andej dhe po përpiqemi t'i grumbullojmë në mikroshërbime, por thelbi do të mbetet. Është e vështirë për mua tani të imagjinoj se ne do të zëvendësojmë të gjitha sistemet kryesore atje dhe do të kalojmë shpejt në anën tjetër, të ndritshme të sistemeve të reja.
Unë jam mbështetës i faktit se gjithçka që është më afër klientit dhe konsumatorit është aty ku është përfitimi dhe vlera më e madhe e biznesit, ku përshtatshmëria dhe fokusimi në shpejtësi, në ndryshim, në "provo, anuloje, ripërdor, bëj diçka ndryshe" janë nevojiten "-këtu do të ndryshojë peizazhi. Dhe produktet në kuti nuk përshtaten shumë mirë atje. Të paktën ne nuk e shohim. Aty kërkohen zgjidhjet më të lehta dhe më të thjeshta.
Ne shohim këtë zhvillim:
- sistemet bazë të informacionit (kryesisht back office);
- shtresat e mesme në formën e mikroshërbimeve lidhin bërthamën, grumbullojnë, krijojnë një cache, etj.
- sistemet e vijës së përparme kanë për qëllim konsumatorin;
- një shtresë integruese që përgjithësisht është e integruar në tregje, sisteme të tjera dhe ekosisteme. Kjo shtresë është sa më e lehtë, e thjeshtë dhe përmban një minimum të logjikës së biznesit.
Por në të njëjtën kohë, unë jam mbështetës i vazhdimit të përdorimit të parimeve të vjetra nëse ato përdoren siç duhet.
Le të themi se keni një sistem klasik sipërmarrjeje. Ndodhet në peizazhin e një shitësi dhe përbëhet nga dy module që punojnë me njëri-tjetrin. Ekziston gjithashtu një ndërfaqe standarde e integrimit. Pse ta ribëni dhe të sillni një mikroshërbim atje?
Por kur ka 5 module në zyrën e pasme, nga të cilat pjesë të informacionit mblidhen në një proces biznesi, i cili më pas përdoret nga 8-10 sisteme të linjës së përparme, përfitimi vihet re menjëherë. Ju merrni nga pesë sisteme back-office dhe krijoni një shërbim, një të izoluar, që fokusohet në procesin e biznesit. Bëni shërbimin teknologjikisht të avancuar - në mënyrë që të ruajë informacionin në memorie dhe të jetë tolerant ndaj gabimeve, si dhe të punojë me dokumente ose subjekte biznesi. Dhe ju e integroni atë sipas një parimi të vetëm me të gjitha produktet e linjës së parë. Ata anuluan produktin e linjës së përparme - ata thjesht fikën integrimin. Nesër duhet të shkruani një aplikacion celular ose të bëni një uebsajt të vogël dhe të vendosni vetëm një pjesë në funksionalitet - gjithçka është e thjeshtë: e keni montuar si një konstruktor. Unë shoh më shumë zhvillim në këtë drejtim - të paktën në vendin tonë.
Aleksandri:
Sergey përshkroi plotësisht qasjen tonë, faleminderit. Unë thjesht do të them se ku nuk do të shkojmë patjetër - në pjesën thelbësore, në temën e faturimit në internet. Kjo do të thotë, vlerësimi dhe tarifimi do të mbeten, në fakt, një shirës "i madh" që do të shlyejë me siguri para. Dhe ky sistem do të vazhdojë të certifikohet nga autoritetet tona rregullatore. Gjithçka tjetër që shikon drejt klientëve, natyrisht, janë mikroshërbime.
Dmitri:
Këtu certifikimi është një histori. Ndoshta më shumë mbështetje. Nëse shpenzoni pak në mbështetje ose sistemi nuk kërkon mbështetje dhe modifikim, është më mirë të mos e prekni. Një kompromis i arsyeshëm.
Si të zhvillohen mikroshërbime të besueshme
Dmitri:
Mirë. Por unë jam ende i interesuar. Tani po tregoni një histori suksesi: gjithçka ishte në rregull, ne kaluam në mikroshërbime, mbrojtëm idenë për biznesin dhe gjithçka funksionoi. Por kam dëgjuar histori të tjera.
Disa vjet më parë, një kompani zvicerane që kishte investuar dy vjet në zhvillimin e një platforme të re mikroshërbimi për bankat përfundimisht e mbylli projektin. Plotësisht i shembur. Shumë miliona franga zvicerane u shpenzuan dhe në fund ekipi u shpërnda - nuk funksionoi.
Keni pasur histori të ngjashme? Kishte apo ka ndonjë vështirësi? Për shembull, mirëmbajtja e mikroshërbimeve dhe monitorimi është gjithashtu një dhimbje koke në aktivitetet operacionale të kompanisë. Në fund të fundit, numri i komponentëve rritet dhjetëra herë. Si e shihni, a ka pasur shembuj të pasuksesshëm investimesh këtu? Dhe çfarë mund t'i këshilloni njerëzit që të mos hasin probleme të tilla?
Aleksandri:
Shembujt e pasuksesshëm përfshijnë bizneset që ndryshojnë prioritetet dhe anulojnë projektet. Kur në një fazë të mirë gatishmërie (në fakt, MVP është gati), biznesi tha: "Ne kemi prioritete të reja, po kalojmë në një projekt tjetër dhe po e mbyllim këtë."
Nuk kemi pasur asnjë dështim global me mikroshërbimet. Ne flemë të qetë, kemi një turn 24/7 që shërben të gjithë BSS [sistemi i mbështetjes së biznesit].
Dhe një gjë tjetër - ne japim mikroshërbime me qira sipas rregullave që vlejnë për produktet e paketuara. Çelësi i suksesit është se ju duhet, së pari, të grumbulloni një ekip që do të përgatisë plotësisht mikro-shërbimin për prodhim. Vetë zhvillimi është, me kusht, 40%. Pjesa tjetër është analitika, metodologjia DevSecOps, integrimet e duhura dhe arkitektura e duhur. Ne i kushtojmë vëmendje të veçantë parimeve të ndërtimit të aplikacioneve të sigurta. Përfaqësuesit e sigurisë së informacionit marrin pjesë në çdo projekt si në fazën e planifikimit të arkitekturës ashtu edhe gjatë procesit të zbatimit. Ata gjithashtu menaxhojnë sistemet për analizimin e kodit për dobësitë.
Le të themi se ne përdorim shërbimet tona pa shtetësi - ne i kemi ato në Kubernetes. Kjo i lejon të gjithë të flenë të qetë për shkak të shkallëzimit automatik dhe ngritjes automatike të shërbimeve, dhe ndërrimi i detyrës merr incidente.
Gjatë gjithë ekzistencës së mikroshërbimeve tona, ka pasur vetëm një ose dy incidente që kanë arritur në linjën tonë. Tani nuk ka probleme me funksionimin. Ne, natyrisht, nuk kemi 200, por rreth 50 mikroshërbime, por ato përdoren në produktet kryesore. Nëse ata dështuan, ne do të ishim të parët që do të dinim për këtë.
Microservices dhe HR
Sergey:
Unë jam dakord me kolegun tim për transferimin në mbështetje - që puna duhet të organizohet në mënyrë korrekte. Por unë do t'ju tregoj për problemet që, natyrisht, ekzistojnë.
Së pari, teknologjia është e re. Kjo është një reklamë në një mënyrë të mirë, dhe gjetja e një specialisti që do ta kuptojë dhe mund ta krijojë këtë është një sfidë e madhe. Konkurrenca për burime është e çmendur, kështu që ekspertët ia vlejnë peshën e tyre në ar.
Së dyti, me krijimin e peizazheve të caktuara dhe një numër në rritje të shërbimeve, problemi i ripërdorimit duhet të zgjidhet vazhdimisht. Siç u pëlqen të bëjnë zhvilluesit: "Le të shkruajmë shumë gjëra interesante këtu tani..." Për shkak të kësaj, sistemi rritet dhe humbet efektivitetin e tij për sa i përket parave, kostos së pronësisë etj. Kjo do të thotë, është e nevojshme të përfshihet ripërdorimi në arkitekturën e sistemit, ta përfshijë atë në udhërrëfyesin për prezantimin e shërbimeve dhe transferimin e trashëgimisë në një arkitekturë të re.
Një problem tjetër - edhe pse kjo është e mirë në mënyrën e vet - është konkurrenca e brendshme. "Oh, djem të rinj në modë janë shfaqur këtu, ata flasin një gjuhë të re." Njerëzit, natyrisht, janë të ndryshëm. Ka nga ata që janë mësuar të shkruajnë në Java, dhe nga ata që shkruajnë dhe përdorin Docker dhe Kubernetes. Këta janë njerëz krejtësisht të ndryshëm, ata flasin ndryshe, përdorin terma të ndryshëm dhe ndonjëherë nuk e kuptojnë njëri-tjetrin. Aftësia ose pamundësia për të ndarë praktikën, shkëmbimin e njohurive, në këtë kuptim është gjithashtu një problem.
Epo, shkallëzimi i burimeve. “Shkëlqyeshëm, le të shkojmë! Dhe tani ne duam më shpejt, më shumë. Çfarë, nuk mundesh? A nuk është e mundur të dorëzosh dy herë më shumë në një vit? Dhe pse?" Dhimbje të tilla në rritje janë ndoshta standarde për shumë gjëra, shumë qasje dhe ju mund t'i ndjeni ato.
Në lidhje me monitorimin. Më duket se shërbimet ose mjetet e monitorimit industrial tashmë po mësojnë ose janë në gjendje të punojnë me Docker dhe Kubernetes në një mënyrë të ndryshme, jo standarde. Kështu që, për shembull, të mos përfundoni me 500 makina Java nën të cilat funksionon e gjithë kjo, domethënë, ajo grumbullohet. Por këtyre produkteve ende u mungon pjekuria; ata duhet ta kalojnë këtë. Tema është vërtet e re, do të vazhdojë të zhvillohet.
Dmitri:
Po, shumë interesante. Dhe kjo vlen për HR. Ndoshta procesi juaj i burimeve njerëzore dhe marka e burimeve njerëzore kanë ndryshuar pak gjatë këtyre 3 viteve. Filluat të rekrutoni njerëz të tjerë me kompetenca të ndryshme. Dhe ndoshta ka të mirat dhe të këqijat. Më parë, blockchain dhe shkenca e të dhënave ishin reklama, dhe specialistët në to vlejnë miliona. Tani kostoja po bie, tregu po ngopet dhe ka një tendencë të ngjashme në mikroshërbimet.
Sergey:
Po, absolutisht.
Aleksandri:
HR bën pyetjen: "Ku është njëbrirëshi juaj rozë midis pjesës së pasme dhe pjesës së përparme?" HR nuk e kupton se çfarë është një mikroshërbim. Ne u thamë sekretin dhe u thamë se backend bëri gjithçka, dhe nuk ka njëbrirësh. Por HR po ndryshon, po mëson shpejt dhe po rekruton njerëz që kanë njohuri bazë të IT-së.
Evolucioni i mikroshërbimeve
Dmitri:
Nëse shikoni arkitekturën e synuar, mikroshërbimet duken si një përbindësh i tillë. Udhëtimi juaj zgjati disa vjet. Të tjerët kanë një vit, të tjerët tre vjet. A i keni parashikuar të gjitha problemet, arkitekturën e synuar, a ka ndryshuar ndonjë gjë? Për shembull, në rastin e mikroshërbimeve, portat dhe rrjetat e shërbimit tani shfaqen përsëri. I keni përdorur në fillim apo keni ndryshuar vetë arkitekturën? Keni sfida të tilla?
Sergey:
Ne kemi rishkruar tashmë disa protokolle komunikimi. Në fillim kishte një protokoll, tani kaluam në një tjetër. Ne rrisim sigurinë dhe besueshmërinë. Ne filluam me teknologjitë e ndërmarrjeve - Oracle, Web Logic. Tani po largohemi nga produktet e ndërmarrjeve teknologjike në mikroshërbime dhe po kalojmë në teknologji me burim të hapur ose plotësisht të hapur. Ne braktisim bazat e të dhënave dhe kalojmë në atë që funksionon më efektivisht për ne në këtë model. Nuk kemi më nevojë për teknologjitë Oracle.
Ne filluam thjesht si një shërbim, pa menduar se sa shumë kishim nevojë për një cache, çfarë do të bënim kur nuk kishte lidhje me një mikroshërbim, por duheshin të dhëna etj. Tani po zhvillojmë një platformë që të mund të përshkruhet arkitektura jo në gjuhën e shërbimeve, dhe në gjuhën e biznesit, logjikën e biznesit e çoni në një nivel tjetër kur fillojmë të flasim me fjalë. Tani kemi mësuar të flasim me shkronja, dhe niveli tjetër është kur shërbimet do të grumbullohen në një lloj agregati, kur kjo tashmë është një fjalë - për shembull, një kartë e tërë produkti. Është mbledhur nga mikroshërbime, por është një API i ndërtuar mbi këtë.
Siguria është shumë e rëndësishme. Sapo filloni të jeni të aksesueshëm dhe keni një shërbim përmes të cilit mund të merrni shumë gjëra interesante dhe shumë shpejt, në një sekondë, atëherë lind dëshira për ta marrë atë në një mënyrë jo më të sigurt. Për t'u larguar nga kjo, na u desh të ndryshonim qasjet ndaj testimit dhe monitorimit. Na u desh të ndryshonim ekipin, strukturën e menaxhimit të dërgesave, CI/CD.
Ky është një evolucion - si me telefonat, vetëm shumë më i shpejtë: fillimisht kishte telefona me butona, pastaj u shfaqën telefonat inteligjentë. Ata rishkruan dhe ridizajnuan produktin sepse tregu kishte një nevojë tjetër. Kështu evoluojmë ne: klasa e parë, klasa e dhjetë, puna.
Në mënyrë të përsëritur, diçka shtrohet në vit nga pikëpamja e teknologjisë, diçka tjetër nga pikëpamja e ngarkesës dhe nevojave. Ne lidhim një gjë me një tjetër. Ekipi shpenzon 20% për borxhin teknik dhe mbështetjen teknike për ekipin, 80% për subjektin afarist. Dhe ne lëvizim duke kuptuar pse po e bëjmë atë, pse po i bëjmë këto përmirësime teknologjike, në çfarë do të çojnë ato. Ashtu si kjo.
Dmitri:
I ftohtë. Çfarë ka në MegaFon?
Aleksandri:
Sfida kryesore kur erdhëm te mikroshërbimet ishte të mos bieshim në kaos. Zyra arkitekturore e MegaFon menjëherë na u bashkua, madje u bë iniciator dhe drejtues - tani kemi një arkitekturë shumë të fortë. Detyra e tij ishte të kuptonte se në cilin model synojmë do të shkojmë dhe cilat teknologji duhet të pilotohen. Me arkitekturë, ne i kryenim vetë këta pilotë.
Pyetja tjetër ishte: "Atëherë si të shfrytëzohet e gjithë kjo?" Dhe një tjetër: "Si të sigurohet ndërveprim transparent midis mikroshërbimeve?" Rrjeta e shërbimit na ndihmoi t'i përgjigjemi pyetjes së fundit. Ne pilotuam Istion dhe na pëlqyen rezultatet. Tani jemi në fazën e hyrjes në zonat prodhuese. Ne kemi një qëndrim pozitiv ndaj të gjitha sfidave - fakti që duhet të ndryshojmë vazhdimisht rafte, të mësojmë diçka të re. Ne jemi të interesuar të zhvillojmë, jo të shfrytëzojmë zgjidhjet e vjetra.
Dmitri:
Fjalë të arta! Sfida të tilla e mbajnë ekipin dhe biznesin në këmbë dhe krijojnë të ardhmen. GDPR krijoi zyrtarët kryesorë të mbrojtjes së të dhënave dhe sfidat aktuale krijojnë zyrtarët kryesorë të mikroshërbimeve dhe arkitekturës. Dhe kënaqet.
Kemi diskutuar shumë. Gjëja kryesore është që një dizajn i mirë i mikroshërbimeve dhe vetë arkitektura ju lejon të shmangni shumë gabime. Sigurisht, procesi është përsëritës dhe evolucionar, por është e ardhmja.
Faleminderit të gjithë pjesëmarrësve, falë Sergeit dhe Aleksandrit!
Pyetje nga auditori
Pyetje nga auditori (1):
Sergey, si ka ndryshuar menaxhimi i IT në kompaninë tuaj? Unë e kuptoj se kur ka një grumbull të madh të disa sistemeve, mënyra se si menaxhohet është një proces mjaft i qartë dhe logjik. Si e rindërtuat menaxhimin e komponentit të IT pasi një numër shumë i madh mikroshërbimesh u integruan në një kohë kaq të shkurtër?
Sergey:
Jam dakord me kolegun tim se arkitektura është shumë e rëndësishme si një shtytës i ndryshimit. Filluam duke pasur një ndarje arkitekturore. Arkitektët janë njëkohësisht pronarë të shpërndarjes së funksionalitetit dhe kërkesave për mënyrën se si ai do të shfaqet në peizazh. Pra, ata veprojnë edhe si koordinatorë të këtyre ndryshimeve. Si rezultat, pati ndryshime specifike në një proces specifik dërgimi kur krijuam një platformë CI/CD.
Por standardi, parimet bazë të zhvillimit, analizës së biznesit, testimit dhe zhvillimit nuk janë anuluar. Ne thjesht shtuam shpejtësinë. Më parë, cikli kërkonte kaq shumë, instalimi në mjediset e testimit kërkonte shumë më tepër. Tani biznesi e sheh përfitimin dhe thotë: "Pse nuk mund të bëjmë të njëjtën gjë në vende të tjera?"
Është si, në një mënyrë të mirë, një injeksion në formën e një vaksine që tregoi: mund ta bësh në këtë mënyrë, por mund ta bësh në një mënyrë tjetër. Sigurisht që ka problem në personel, në kompetenca, në dije, në rezistencë.
Pyetje nga auditori (2):
Kritikët e arkitekturës së mikroshërbimeve thonë se testimi dhe zhvillimi janë të vështira. Kjo është logjike ku gjërat ndërlikohen. Me çfarë sfidash u përball ekipi juaj dhe si i kapërceni ato? Pyetje për të gjithë.
Aleksandri:
Ka vështirësi kur kaloni nga mikroshërbimet në një platformë, por ato mund të zgjidhen.
Për shembull, ne po bëjmë një produkt që përbëhet nga 5-7 mikroshërbime. Ne duhet të ofrojmë teste integrimi në të gjithë grupin e mikroshërbimeve për të dhënë dritën jeshile për të kaluar në degën kryesore. Kjo detyrë nuk ishte e re për ne: ne e kishim bërë këtë për një kohë të gjatë në BSS, kur shitësi na furnizoi me zgjidhje tashmë të dërguara.
Dhe problemi ynë është vetëm në ekipin e vogël. Për një produkt të kushtëzuar nevojitet një inxhinier i QA. Dhe kështu, ne dërgojmë një produkt prej 5-7 mikroshërbimesh, nga të cilat 2-3 mund të zhvillohen nga palë të treta. Për shembull, ne kemi një produkt në zhvillimin e të cilit marrin pjesë shitësi ynë i sistemit të faturimit, Mail.ru Group dhe MegaFon R&D. Ne duhet ta mbulojmë këtë me teste përpara se ta dërgojmë në prodhim. Inxhinieri i QA ka një muaj e gjysmë që punon për këtë produkt dhe pjesa tjetër e ekipit ka mbetur pa mbështetjen e tij.
Ky kompleksitet shkaktohet vetëm nga shkallëzimi. Ne e kuptojmë se mikroshërbimet nuk mund të ekzistojnë në vakum; izolimi absolut nuk ekziston. Kur ndryshojmë një shërbim, ne gjithmonë përpiqemi të ruajmë kontratën API. Nëse diçka ndryshon nën kapuç, shërbimi i përparmë mbetet. Nëse ndryshimet janë fatale, ndodh një lloj transformimi arkitektonik dhe ne kalojmë në një metamodel krejtësisht të ndryshëm të të dhënave, i cili është plotësisht i papajtueshëm - vetëm atëherë flasim për paraqitjen e specifikimit të shërbimit v2 API. Ne mbështesim versionin e parë dhe të dytë në të njëjtën kohë, dhe pasi të gjithë konsumatorët kalojnë në versionin e dytë, ne thjesht mbyllim të parën.
Sergey:
dua të shtoj. Unë jam plotësisht dakord për komplikimet - ato ndodhin. Peizazhi po bëhet më kompleks dhe kostot e përgjithshme po rriten, veçanërisht për testimin. Si të merreni me këtë: kaloni në testimin e automatizuar. Po, do t'ju duhet të investoni shtesë në shkrimin e autotesteve dhe testeve të njësive. Kështu që zhvilluesit nuk mund të angazhoheshin pa kaluar testin, ata nuk mund ta ndryshonin kodin. Kështu që edhe butoni i shtypjes të mos funksionojë pa autotest, test njësi.
Është e rëndësishme të ruani funksionalitetin e mëparshëm, dhe kjo është shpenzim shtesë. Nëse rishkruani një teknologji në një protokoll tjetër, atëherë e rishkruani atë derisa të mbyllni gjithçka plotësisht.
Ne ndonjëherë nuk bëjmë testime nga fundi në fund me qëllim, sepse nuk duam të ndalojmë zhvillimin, megjithëse kemi gjithashtu një gjë pas tjetrës. Peizazhi është shumë i madh, kompleks, ka shumë sisteme. Ndonjëherë janë thjesht cungje - po, ju ulni marzhin e sigurisë, shfaqen më shumë rreziqe. Por në të njëjtën kohë ju lironi furnizimin.
Aleksandri:
Po, autotestet dhe testet e njësive ju lejojnë të krijoni një shërbim me cilësi të lartë. Jemi për një tubacion që nuk mund të kalohet pa teste njësie dhe integrimi. Shpesh na duhet të tërheqim emulatorët dhe sistemet komerciale në zonat e testimit dhe mjediset e zhvillimit, sepse jo të gjitha sistemet mund të vendosen në zonat e testimit. Për më tepër, ata jo vetëm që lagen - ne gjenerojmë një përgjigje të plotë nga sistemi. Kjo është një pjesë serioze e punës me mikroshërbimet dhe ne po investojmë gjithashtu në të. Pa këtë, do të ndodhë kaos.
Pyetje nga auditori (3):
Me sa kuptoj unë, mikroshërbimet fillimisht u rritën nga një ekip i veçantë dhe tani ekzistojnë në këtë model. Cilat janë të mirat dhe të këqijat e saj?
Ne kemi vetëm një histori të ngjashme: u ngrit një lloj fabrike mikroshërbimesh. Tani ne kemi arritur konceptualisht në pikën që ne po e zgjerojmë këtë qasje në prodhimin sipas rrjedhave dhe sistemeve. Me fjalë të tjera, ne po largohemi nga zhvillimi i centralizuar i mikroshërbimeve, modeleve të mikroshërbimeve dhe po afrohemi me sistemet.
Prandaj, funksionimi ynë shkon edhe në sisteme, domethënë ne po e decentralizojmë këtë temë. Cila është qasja juaj dhe cila është historia juaj e synuar?
Aleksandri:
Ju hoqët menjëherë nga goja emrin "fabrika e mikroshërbimeve" - ne gjithashtu duam të shkallëzojmë. Së pari, ne kemi vërtet një ekip tani. Ne duam t'u ofrojmë të gjitha ekipeve të zhvillimit që ka MegaFon mundësinë për të punuar në një ekosistem të përbashkët. Ne nuk duam të marrim plotësisht përsipër të gjithë funksionalitetin e zhvillimit që kemi tani. Detyra lokale është të shkallëzohet, detyra globale është të drejtojë zhvillimin tek të gjitha ekipet në shtresën e mikroservisit.
Sergey:
Unë do t'ju tregoj rrugën që kemi marrë. Me të vërtetë filluam të punojmë si një ekip, por tani nuk jemi vetëm. Unë jam ithtar i sa vijon: duhet të ketë një pronar të procesit. Dikush duhet të kuptojë, menaxhojë, kontrollojë dhe ndërtojë procesin e zhvillimit të mikroshërbimeve. Ai duhet të zotërojë burime dhe të angazhohet në menaxhimin e burimeve.
Këto burime, të cilët njohin teknologjitë, specifikat dhe kuptojnë se si të ndërtojnë mikroshërbime, mund të vendosen në ekipet e produkteve. Ne kemi një përzierje ku njerëzit nga platforma mikroservice janë në ekipin e produktit që bën aplikacionin celular. Ata janë aty, por punojnë sipas procesit të departamentit të menaxhimit të platformës së mikroservisit me menaxherin e tyre të zhvillimit. Brenda këtij divizioni ka një ekip të veçantë që merret me teknologjinë. Kjo do të thotë, ne përziejmë një grup të përbashkët burimesh midis nesh dhe i ndajmë ato, duke ua dhënë ekipeve.
Në të njëjtën kohë, procesi mbetet i përgjithshëm, i kontrolluar, ai vazhdon sipas parimeve të përgjithshme teknologjike, me testimin e njësisë dhe kështu me radhë - gjithçka që është ndërtuar në krye. Mund të ketë kolona në formën e burimeve të mbledhura nga departamente të ndryshme të qasjes së produktit.
Aleksandri:
Sergej, ju jeni në të vërtetë pronari i procesit, apo jo? A ndahet numri i detyrave të mbetura? Kush është përgjegjës për shpërndarjen e tij?
Sergey:
Shikoni: këtu është përzierja përsëri. Ka një grumbull të mbetur që është formuar bazuar në përmirësimet teknologjike - kjo është një histori. Ka një prapambetje, e cila është formuluar nga projektet, dhe ka një prapambetje nga produktet. Por sekuenca e futjes në secilin prej produkteve të shërbimit ose krijimi i këtij shërbimi zhvillohet nga një specialist produkti. Ai nuk është në drejtorinë e TI-së, ai u hoq posaçërisht nga ajo. Por njerëzit e mi sigurisht që punojnë sipas të njëjtit proces.
Pronari i ngarkesës së mbetur në drejtime të ndryshme - numri i ndryshimeve - do të jenë njerëz të ndryshëm. Lidhja e shërbimeve teknologjike, parimi i organizimit të tyre - e gjithë kjo do të jetë në IT. Unë zotëroj platformën dhe burimet gjithashtu. Në krye është ajo që ka të bëjë me ndryshimet e prapambetura dhe funksionale, dhe arkitekturën në këtë kuptim.
Le të themi se një biznes thotë: "Ne duam këtë funksion, ne duam të krijojmë një produkt të ri - të rimarrë një kredi." Ne përgjigjemi: "Po, do ta ribëjmë". Arkitektët thonë: "Le të mendojmë: ku do të shkruajmë mikroshërbime në kredi dhe si do ta bëjmë atë?" Më pas e ndajmë në projekte, produkte ose në një grumbull teknologjie, e vendosim në ekipe dhe e zbatojmë. A keni krijuar një produkt nga brenda dhe keni vendosur të përdorni mikroshërbime në këtë produkt? Ne themi: "Tani sistemet e trashëguara që kishim, ose sistemet e vijës së parë, duhet të kalojnë në këto mikroshërbime." Arkitektët thonë: "Pra: në prapambetjen teknologjike brenda produkteve të linjës së përparme - kalimi në mikroshërbime. Shko". Dhe specialistët e produkteve ose pronarët e bizneseve e kuptojnë se sa kapacitet është ndarë, kur do të bëhet dhe pse.
Fundi i diskutimit, por jo i gjithë
U organizua konferenca mailto:CLOUD .
Bëjmë edhe evente të tjera - p.sh. Takimi @Kubernetes, ku ne jemi gjithmonë në kërkim të folësve të shkëlqyer:
- Ndiqni @Kubernetes dhe lajme të tjera @Meetup në kanalin tonë Telegram
- Jeni të interesuar të flisni në një nga @Meetups? Lini një kërkesë për
Burimi: www.habr.com