Noong Abril 25, kami sa Mail.ru Group ay nagsagawa ng isang kumperensya tungkol sa mga ulap at sa paligid - . Ilang highlight:
- Pangunahing β Ang Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center at Yandex.Cloud ay nagsalita tungkol sa mga detalye ng aming cloud market at kanilang mga serbisyo;
- Sinabi ng mga kasamahan mula sa Bitrix24 kung paano sila ;
- Nagbigay ng interesante sina Leroy Merlin, Otkritie, Burger King at Schneider Electric β kung anong mga gawain ang itinakda ng kanilang negosyo para sa IT at kung anong mga teknolohiya, kabilang ang mga cloud, ang nakikita nilang pinakapangako.
Maaari mong panoorin ang lahat ng mga video mula sa mailto:CLOUD conference , at dito mo mababasa kung paano napunta ang talakayan tungkol sa mga microservice. Alexander Deulin, pinuno ng MegaFon business systems research and development center, at Sergey Sergeev, information technology director ng M.Video-Eldorado group, ay nagbahagi ng kanilang matagumpay na mga kaso ng pag-alis ng mga monolith. Tinalakay din namin ang mga kaugnay na isyu ng diskarte sa IT, mga proseso at maging ang HR.
Mga panelista
- Sergey Sergeev, Group CIO "M.Video-Eldorado";
- Alexander Deulin, pinuno ng sentro para sa pananaliksik at pagpapaunlad ng mga sistema ng negosyo MegaFon;
- Moderator - Dmitry Lazarenko, Pinuno ng direksyon ng PaaS Mail.ru Cloud Solutions.
Pagkatapos ng talumpati ni Alexander Deulin sinamahan siya para sa talakayan ni Sergey Sergeev mula sa M.Video-Eldorado at moderator ng talakayan na si Dmitry Lazarenko, Mail.ru Cloud Solutions.
Sa ibaba ay naghanda kami ng transcript ng talakayan para sa iyo, ngunit maaari mo ring panoorin ang video:
Ang paglipat sa mga microservice ay isang tugon sa mga pangangailangan sa merkado
Dmitriy:
Nagkaroon ka na ba ng anumang matagumpay na karanasan sa paglipat sa mga microservice? At sa pangkalahatan: saan mo nakikita ang pinakamalaking benepisyo sa negosyo mula sa paggamit ng mga microservice o paglipat mula sa mga monolith patungo sa mga microservice?
Sergey:
Nakarating na kami sa ilang paraan sa paglipat sa mga microservice at ginagamit na ang diskarteng ito nang higit sa tatlong taon. Ang unang pangangailangan na nagbigay-katwiran sa pangangailangan para sa mga microservice ay ang walang katapusang pagsasama ng iba't ibang mga front-end na produkto sa back office. At sa bawat oras na napipilitan kaming gumawa ng karagdagang pagsasama at pag-unlad, na nagpapatupad ng aming sariling mga patakaran para sa pagpapatakbo ng ito o ang serbisyong iyon.
Sa isang punto, napagtanto namin na kailangan naming pabilisin ang pagpapatakbo ng aming mga system at ang output ng functionality. Sa sandaling iyon, umiral na sa merkado ang mga konsepto tulad ng microservices at isang microservice approach, at nagpasya kaming subukan ito. Nagsimula ito noong 2016. Pagkatapos ay inilatag ang plataporma at ang unang 10 serbisyo ay ipinatupad ng isang hiwalay na pangkat.
Isa sa mga unang serbisyo, ang pinakamabigat na load, ay ang serbisyo sa pagkalkula ng presyo. Sa tuwing pupunta ka sa anumang channel, sa grupo ng mga kumpanya ng M.Video-Eldorado, maging isang website o retail store, pumili ng isang produkto doon, tingnan ang presyo sa website o sa "Basket", ang gastos ay awtomatikong kinakalkula ng isang serbisyo. Bakit ito kinakailangan: bago ito, ang bawat sistema ay may sariling mga prinsipyo para sa pagtatrabaho sa mga promosyon - na may mga diskwento at iba pa. Ang aming back office ang humahawak sa pagpepresyo; ang pagpapagana ng diskwento ay ipinapatupad sa ibang system. Kailangan itong maging sentralisado at isang natatanging, mapaghihiwalay na serbisyo na ginawa sa anyo ng isang proseso ng negosyo na magpapahintulot sa amin na ipatupad ito. Ganyan talaga kami nagsimula.
Ang halaga ng mga unang resulta ay napakahusay. Una, nakagawa kami ng mga mapaghihiwalay na entity na nagbibigay-daan sa aming magtrabaho nang hiwalay at sa pinagsama-samang paraan. Pangalawa, binawasan namin ang halaga ng pagmamay-ari sa mga tuntunin ng pagsasama sa mas maraming system.
Sa nakalipas na tatlong taon, nagdagdag kami ng tatlong frontline system. Mahirap na panatilihin ang mga ito sa parehong halaga ng mga mapagkukunan na kayang bayaran ng kumpanya. Samakatuwid, ang gawain ay lumitaw upang maghanap ng mga bagong saksakan, na tumutugon sa merkado sa mga tuntunin ng bilis, sa mga tuntunin ng mga panloob na gastos at kahusayan.
Paano sukatin ang tagumpay ng paglipat sa mga microservice
Dmitriy:
Paano natutukoy ang tagumpay sa paglipat sa mga microservice? Ano ang "noon" sa bawat kumpanya? Anong sukatan ang ginamit mo upang matukoy ang tagumpay ng paglipat, at sino talaga ang nagtukoy nito?
Sergey:
Una sa lahat, ipinanganak ito sa loob ng IT bilang isang enabler - "pag-unlock" ng mga bagong kakayahan. Kailangan naming gawin ang lahat nang mas mabilis para sa medyo parehong pera, na tumutugon sa mga hamon sa merkado. Ngayon ang tagumpay ay ipinahayag sa bilang ng mga serbisyo na muling ginagamit ng iba't ibang mga sistema, pag-iisa ng mga proseso sa kanilang mga sarili. Ngayon ay, ngunit sa sandaling iyon ito ay isang pagkakataon upang lumikha ng isang platform at kumpirmahin ang hypothesis na magagawa natin ito, ito ay magbibigay ng epekto at kalkulahin ang kaso ng negosyo.
Alexander:
Ang tagumpay ay sa halip ay isang panloob na pakiramdam. Palaging gusto ng negosyo ang higit pa, at ang lalim ng ating backlog ay patunay ng tagumpay. Parang ganun sa akin.
Sergey:
Oo Sumasang-ayon ako. Sa tatlong taon, mayroon na tayong mahigit dalawang daang serbisyo at backlog. Ang pangangailangan para sa mga mapagkukunan sa loob ng koponan ay lumalaki lamang - sa pamamagitan ng 30% taun-taon. Nangyayari ito dahil naramdaman ng mga tao: ito ay mas mabilis, ito ay naiiba, mayroong iba't ibang mga teknolohiya, lahat ng ito ay umuunlad.
Darating ang mga microservice, ngunit mananatili ang core
Dmitriy:
Ito ay tulad ng isang walang katapusang proseso kung saan namumuhunan ka sa pag-unlad. Tapos na ba ang paglipat sa microservices para sa negosyo o hindi pa?
Sergey:
Napakadaling sagutin. Ano sa palagay mo: ang pagpapalit ng mga telepono ay isang walang katapusang proseso? Kami mismo ang bumibili ng mga telepono bawat taon. At narito: hangga't may pangangailangan para sa bilis, para sa pagbagay sa merkado, kakailanganin ang ilang mga pagbabago. Hindi ito nangangahulugan na abandunahin natin ang mga karaniwang bagay.
Ngunit hindi namin maaaring takpan at gawing muli ang lahat nang sabay-sabay. Mayroon kaming legacy, karaniwang mga serbisyo sa pagsasama na umiral noon: mga bus ng negosyo at iba pa. Pero may atraso, at kailangan din. Ang bilang ng mga mobile application at ang kanilang functionality ay lumalaki. At the same time, walang nagsasabi na bibigyan ka ng 30% more money. Iyon ay, palaging may mga pangangailangan sa isang banda, at isang paghahanap para sa kahusayan sa kabilang banda.
Dmitriy:
Ang buhay ay nasa mabuting kalagayan. (Tumawa)
Alexander:
Sa pangkalahatan, oo. Wala kaming mga rebolusyonaryong diskarte sa pag-alis ng pangunahing bahagi mula sa landscape. Ang sistematikong gawain ay isinasagawa upang mabulok ang mga sistema upang mas maging pare-pareho ang mga ito sa arkitektura ng microservice, upang mabawasan ang impluwensya ng mga system sa isa't isa.
Ngunit pinaplano naming panatilihin ang pangunahing bahagi, dahil sa landscape ng operator ay palaging may ilang mga platform na bibilhin namin. Muli, kailangan natin ng malusog na balanse: hindi tayo dapat magmadali sa pagputol ng core. Inilalagay namin ang mga system nang magkatabi, at ngayon ay lumalabas na kami ay nasa tuktok ng maraming mga pangunahing bahagi. Dagdag pa, sa pagbuo ng functionality, gumagawa kami ng mga kinakailangang representasyon para sa lahat ng channel na gumagana sa aming mga serbisyo sa komunikasyon.
Paano magbenta ng mga microservice sa mga negosyo
Dmitriy:
Interesado din ako - para sa mga hindi pa lumipat, ngunit nagpaplanong: gaano kadaling ibenta ang ideyang ito sa negosyo at ito ba ay isang pakikipagsapalaran, isang proyekto sa pamumuhunan? O ito ba ay isang nakakamalay na diskarte: ngayon ay pupunta kami sa mga microservice at iyon lang, walang makakapigil sa amin. Paano ito para sa iyo?
Sergey:
Hindi kami nagbebenta ng diskarte, ngunit isang benepisyo sa negosyo. Nagkaroon ng problema sa negosyo, at sinubukan naming lutasin ito. Sa sandaling iyon, ito ay ipinahayag sa katotohanan na ang iba't ibang mga channel ay gumagamit ng iba't ibang mga prinsipyo para sa pagkalkula ng mga presyo - hiwalay para sa mga promo, para sa mga promo, at iba pa. Mahirap i-maintain, nagkaroon ng mga error, at nakinig kami sa mga reklamo ng customer. Iyon ay, nagbebenta kami ng solusyon sa isang problema, ngunit dumating kami sa katotohanan na kailangan namin ng pera upang lumikha ng isang platform. At ipinakita nila ang isang kaso ng negosyo gamit ang halimbawa ng unang yugto ng pamumuhunan: kung paano namin ito patuloy na mababawi at kung ano ang papayagan nitong gawin namin.
Dmitriy:
Naitala mo ba kahit papaano ang oras ng unang yugto?
Sergey:
Oo ba. Naglaan kami ng 6 na buwan upang gawin ang core bilang isang platform at subukan ang pilot. Sa panahong ito, sinubukan naming lumikha ng isang platform kung saan i-skate ang piloto. Pagkatapos ay nakumpirma ang hypothesis, at dahil gumagana ito, nangangahulugan ito na maaari tayong magpatuloy. Sinimulan nilang kopyahin at palakasin ang koponan - inilipat nila ito sa isang hiwalay na dibisyon na gumagawa ng ganoon.
Susunod ay ang sistematikong gawain batay sa mga pangangailangan sa negosyo, mga pagkakataon, pagkakaroon ng mga mapagkukunan at lahat ng bagay na kasalukuyang ginagawa.
Dmitriy:
OK. Alexander, anong masasabi mo?
Alexander:
Ang aming mga microservice ay ipinanganak mula sa "foam of the sea" - dahil sa pagtitipid ng mga mapagkukunan, dahil sa ilang natira sa anyo ng kapasidad ng server at ang muling pamamahagi ng mga puwersa sa loob ng koponan. Noong una, hindi namin ibinenta ang proyektong ito sa negosyo. Ito ay isang proyekto kung saan pareho kaming nagsaliksik at binuo nang naaayon. Nagsimula kami sa simula ng 2018 at simpleng binuo ang direksyong ito nang may sigasig. Kakasimula pa lang ng benta at nasa proseso na kami.
Dmitriy:
Nangyayari ba na pinapayagan ka ng isang negosyo na gawin ang mga bagay tulad ng Google - sa isang libreng araw sa isang linggo? Mayroon ka bang ganoong direksyon?
Alexander:
Kasabay ng pananaliksik, hinarap din namin ang mga problema sa negosyo, kaya lahat ng aming microservice ay solusyon sa mga problema sa negosyo. Sa simula pa lamang ay nagtayo kami ng mga microservice na sumasaklaw sa isang maliit na bahagi ng base ng subscriber, at ngayon ay naroroon na kami sa halos lahat ng pangunahing produkto.
At malinaw na ang materyal na epekto - mabibilang na tayo, matantya ang bilis ng paglulunsad ng produkto at nawalang kita kung sinundan natin ang dating landas. Ito ay kung ano ang aming pagbuo ng kaso sa.
Mga Microservice: hype o pangangailangan?
Dmitriy:
Ang mga numero ay mga numero. At ang kita o pera na naipon ay napakahalaga. Paano kung tumingin ka sa kabilang side? Tila uso ang microservices, hype at inaabuso ito ng maraming kumpanya? Gaano mo kalinaw ang pagkakaiba sa pagitan ng iyong ginagawa at hindi isinasalin sa mga microservice? Kung legacy ngayon, magkakaroon ka pa ba ng legacy in 5 years? Ano ang magiging edad ng mga sistema ng impormasyon na gumagana sa M.Video-Eldorado at MegaFon sa loob ng 5 taon? Magkakaroon ba ng sampung taon, labinlimang taong gulang na mga sistema ng impormasyon o magiging isang bagong henerasyon? Paano mo ito nakikita?
Sergey:
Para sa akin ay mahirap mag-isip nang napakalayo. Kung babalikan natin, sino ang nag-akala na ang market ng teknolohiya ay bubuo sa ganitong paraan, kabilang ang machine learning at pagkilala ng user sa pamamagitan ng mukha? Ngunit kung titingnan mo ang mga darating na taon, tila sa akin ang mga pangunahing sistema, enterprise ERP-class system sa mga kumpanya - sila ay nagtatrabaho nang medyo matagal.
Ang aming mga kumpanya ay sama-samang 25 taong gulang, na may klasikong ERP na napakalalim sa landscape ng system. Malinaw na kumukuha kami ng ilang piraso doon at sinusubukang pagsama-samahin ang mga ito sa mga microservice, ngunit mananatili ang core. Mahirap para sa akin ngayon na isipin na papalitan namin ang lahat ng mga pangunahing system doon at mabilis na lumipat sa isa pa, maliwanag na bahagi ng mga bagong system.
Ako ay isang tagasuporta ng katotohanan na ang lahat ng bagay na mas malapit sa kliyente at mamimili ay kung saan ang pinakamalaking benepisyo at halaga ng negosyo, kung saan ang kakayahang umangkop at tumuon sa bilis, sa pagbabago, sa "subukan, kanselahin, muling gamitin, gawin ang isang bagay na naiiba" ay kailangan ββdiyan magbabago ang tanawin. At ang mga naka-box na produkto ay hindi kasya doon. At least hindi natin nakikita. Ang pinakamadali, pinakasimpleng solusyon ay kinakailangan doon.
Nakikita natin ang pag-unlad na ito:
- mga pangunahing sistema ng impormasyon (karamihan sa likod ng opisina);
- ang mga gitnang layer sa anyo ng mga microservice ay kumonekta sa core, pinagsama-sama, lumikha ng isang cache, at iba pa;
- Ang mga front-line system ay naglalayong sa mamimili;
- isang integration layer na karaniwang isinama sa mga marketplace, iba pang system at ecosystem. Ang layer na ito ay kasing liwanag hangga't maaari, simple, at naglalaman ng isang minimum na lohika ng negosyo.
Ngunit sa parehong oras, ako ay isang tagasuporta ng patuloy na paggamit ng mga lumang prinsipyo kung ang mga ito ay ginagamit nang naaangkop.
Sabihin nating mayroon kang klasikong enterprise system. Ito ay matatagpuan sa landscape ng isang vendor at binubuo ng dalawang module na gumagana sa isa't isa. Mayroon ding karaniwang interface ng pagsasama. Bakit muling gagawin at magdala ng microservice doon?
Ngunit kapag mayroong 5 mga module sa likod ng opisina, kung saan ang mga piraso ng impormasyon ay nakolekta sa isang proseso ng negosyo, na pagkatapos ay ginagamit ng 8-10 front-line system, ang benepisyo ay agad na kapansin-pansin. Kumuha ka mula sa limang back-office system at lumikha ng isang serbisyo, isang nakahiwalay, na nakatuon sa proseso ng negosyo. Gawing advanced na teknolohiya ang serbisyo - upang mai-cache nito ang impormasyon at hindi mapagparaya, at gumagana rin sa mga dokumento o entity ng negosyo. At isinasama mo ito ayon sa iisang prinsipyo sa lahat ng mga produktong front-line. Kinansela nila ang front-line na produkto - pinatay lang nila ang pagsasama. Bukas kailangan mong magsulat ng isang mobile application o gumawa ng isang maliit na website at ilagay lamang ang isang bahagi sa pag-andar - lahat ay simple: binuo mo ito tulad ng isang tagabuo. Nakikita ko ang higit na pag-unlad sa direksyong ito - hindi bababa sa ating bansa.
Alexander:
Buong inilarawan ni Sergey ang aming diskarte, salamat. Sasabihin ko lang kung saan tayo tiyak na hindi pupunta - sa pangunahing bahagi, sa paksa ng online na pagsingil. Iyon ay, ang rating at pagsingil ay mananatiling, sa katunayan, isang "malaking" thresher na mapagkakatiwalaang magwawakas ng pera. At ang sistemang ito ay patuloy na sertipikado ng aming mga awtoridad sa regulasyon. Ang lahat ng iba pang tumitingin sa mga kliyente, siyempre, ay mga microservice.
Dmitriy:
Narito ang sertipikasyon ay isang kuwento. Marahil mas maraming suporta. Kung gumastos ka ng kaunti sa suporta o ang system ay hindi nangangailangan ng suporta at pagbabago, mas mahusay na huwag hawakan ito. Isang makatwirang kompromiso.
Paano bumuo ng mga maaasahang microservice
Dmitriy:
ayos lang. Pero interesado pa rin ako. Ngayon ay nagsasabi ka ng isang kuwento ng tagumpay: lahat ay maayos, lumipat kami sa mga microservice, ipinagtanggol ang ideya sa negosyo, at lahat ay naging maayos. Pero may narinig akong ibang kwento.
Ilang taon na ang nakalilipas, isang Swiss na kumpanya na namuhunan ng dalawang taon sa pagbuo ng isang bagong microservice platform para sa mga bangko sa kalaunan ay isinara ang proyekto. Ganap na bumagsak. Maraming milyon-milyong Swiss franc ang ginugol, at sa huli ang koponan ay nagkalat - hindi ito gumana.
Nagkaroon ka na ba ng mga katulad na kwento? Mayroon o mayroon bang anumang mga paghihirap? Halimbawa, ang pagpapanatili ng mga microservice at pagsubaybay ay nakakasakit din ng ulo sa mga aktibidad sa pagpapatakbo ng kumpanya. Pagkatapos ng lahat, ang bilang ng mga bahagi ay tumataas nang sampu-sampung beses. Paano mo ito nakikita, mayroon bang mga hindi matagumpay na halimbawa ng mga pamumuhunan dito? At ano ang maipapayo mo sa mga tao upang hindi sila makatagpo ng gayong mga problema?
Alexander:
Kasama sa mga hindi matagumpay na halimbawa ang mga negosyong nagbabago ng mga priyoridad at pagkansela ng mga proyekto. Kapag nasa magandang yugto ng kahandaan (sa katunayan, handa na ang MVP), sinabi ng negosyo: "Mayroon kaming mga bagong priyoridad, lumipat kami sa isa pang proyekto, at isinasara namin ang isang ito."
Wala kaming anumang mga pandaigdigang pagkabigo sa mga microservice. Tahimik kaming natutulog, mayroon kaming 24/7 duty shift na nagseserbisyo sa buong BSS [business support system].
At isa pang bagay - nagrenta kami ng mga microservice ayon sa mga patakarang naaangkop sa mga produktong naka-box. Ang susi sa tagumpay ay kailangan mo, una, upang bumuo ng isang koponan na ganap na maghahanda ng microservice para sa produksyon. Ang pag-unlad mismo ay, kondisyon, 40%. Ang natitira ay analytics, DevSecOps methodology, tamang pagsasama at tamang arkitektura. Nagbibigay kami ng espesyal na pansin sa mga prinsipyo ng pagbuo ng mga secure na application. Ang mga kinatawan ng seguridad ng impormasyon ay lumahok sa bawat proyekto kapwa sa yugto ng pagpaplano ng arkitektura at sa panahon ng proseso ng pagpapatupad. Pinamamahalaan din nila ang mga system para sa pagsusuri ng code para sa mga kahinaan.
Sabihin nating ini-deploy namin ang aming mga stateless na serbisyo - mayroon kaming mga ito sa Kubernetes. Nagbibigay-daan ito sa lahat na makatulog nang mapayapa dahil sa auto-scaling at auto-raising ng mga serbisyo, at ang duty shift ay nakakakuha ng mga insidente.
Sa buong pagkakaroon ng aming mga microservice, mayroon lamang isa o dalawang insidente na umabot sa aming linya. Ngayon walang mga problema sa operasyon. Siyempre, wala kaming 200, ngunit humigit-kumulang 50 microservice, ngunit ginagamit ang mga ito sa mga produktong punong barko. Kung nabigo sila, kami ang unang makakaalam nito.
Microservices at HR
Sergey:
Sumasang-ayon ako sa aking kasamahan tungkol sa paglipat sa suporta - na ang gawain ay kailangang maayos na maayos. Ngunit sasabihin ko sa iyo ang tungkol sa mga problema na, siyempre, umiiral.
Una, ang teknolohiya ay bago. Ito ay hype sa isang mahusay na paraan, at ang paghahanap ng isang espesyalista na makakaunawa at makakalikha nito ay isang malaking hamon. Ang kumpetisyon para sa mga mapagkukunan ay nakakabaliw, kaya ang mga eksperto ay nagkakahalaga ng kanilang timbang sa ginto.
Pangalawa, sa paglikha ng ilang mga landscape at dumaraming bilang ng mga serbisyo, ang problema sa muling paggamit ay dapat na patuloy na malutas. Tulad ng gustong gawin ng mga developer: "Magsulat tayo ng maraming kawili-wiling bagay dito ngayon..." Dahil dito, lumalaki ang system at nawawala ang pagiging epektibo nito sa mga tuntunin ng pera, halaga ng pagmamay-ari, at iba pa. Ibig sabihin, kinakailangang isama ang muling paggamit sa arkitektura ng system, isama ito sa roadmap para sa pagpapakilala ng mga serbisyo at paglilipat ng legacy sa isang bagong arkitektura.
Ang isa pang problema - kahit na ito ay mabuti sa sarili nitong paraan - ay panloob na kumpetisyon. "Oh, may mga bagong fashionable na lalaki na lumitaw dito, nagsasalita sila ng bagong wika." Ang mga tao, siyempre, ay iba-iba. May mga nakasanayan na magsulat sa Java, at may mga sumusulat at gumagamit ng Docker at Kubernetes. Ito ay ganap na magkakaibang mga tao, sila ay nagsasalita ng iba, gumagamit ng iba't ibang mga termino at kung minsan ay hindi nagkakaintindihan. Ang kakayahan o kawalan ng kakayahang magbahagi ng kasanayan, pagbabahagi ng kaalaman, sa ganitong kahulugan ay isang problema din.
Well, scaling resources. "Ayos! Tara na! At ngayon gusto namin ng mas mabilis, higit pa. Ano, hindi mo kaya? Hindi ba posible na maghatid ng dalawang beses sa isang taon? At bakit?" Ang ganitong mga lumalagong sakit ay malamang na pamantayan para sa maraming bagay, maraming paraan, at mararamdaman mo ang mga ito.
Tungkol sa pagsubaybay. Para sa akin, ang mga serbisyo o mga tool sa pagsubaybay sa industriya ay natututo na o nagagawang magtrabaho kasama ang Docker at Kubernetes sa ibang, hindi karaniwang mode. Upang, halimbawa, hindi ka magkakaroon ng 500 Java machine kung saan tumatakbo ang lahat ng ito, ibig sabihin, ito ay pinagsama-sama. Ngunit ang mga produktong ito ay kulang pa rin sa kapanahunan; kailangan nilang dumaan dito. Ang paksa ay talagang bago, ito ay patuloy na bubuo.
Dmitriy:
Oo, napaka-interesante. At nalalapat ito sa HR. Marahil ang iyong proseso ng HR at tatak ng HR ay nagbago nang kaunti sa loob ng 3 taon na ito. Nagsimula kang mag-recruit ng ibang tao na may iba't ibang kakayahan. At marahil mayroong parehong mga kalamangan at kahinaan. Dati, ang blockchain at data science ay ang hype, at ang mga espesyalista sa kanila ay nagkakahalaga ng milyun-milyon. Ngayon ang gastos ay bumabagsak, ang merkado ay nagiging puspos, at mayroong isang katulad na kalakaran sa microservices.
Sergey:
Oo, ganap.
Alexander:
Tinanong ng HR ang tanong: "Nasaan ang iyong pink na unicorn sa pagitan ng backend at frontend?" Hindi naiintindihan ng HR kung ano ang microservice. Sinabi namin sa kanila ang sikreto at sinabi sa kanila na ginawa ng backend ang lahat, at walang unicorn. Ngunit ang HR ay nagbabago, mabilis na natututo at nagre-recruit ng mga taong may pangunahing kaalaman sa IT.
Ang ebolusyon ng mga microservice
Dmitriy:
Kung titingnan mo ang target na arkitektura, ang mga microservice ay mukhang isang halimaw. Ang iyong paglalakbay ay tumagal ng ilang taon. Ang iba ay may isang taon, ang iba ay tatlong taon. Nakita mo ba ang lahat ng mga problema, ang target na arkitektura, may nagbago ba? Halimbawa, sa kaso ng mga microservice, lumalabas na muli ang mga gateway at service meshes. Ginamit mo ba ang mga ito sa simula o binago mo ba ang mismong arkitektura? Mayroon ka bang ganitong mga hamon?
Sergey:
Nagsulat na kami muli ng ilang protocol ng komunikasyon. Noong una ay may isang protocol, ngayon ay lumipat kami sa isa pa. Pinapataas namin ang kaligtasan at pagiging maaasahan. Nagsimula kami sa mga teknolohiya ng enterprise - Oracle, Web Logic. Ngayon ay lumalayo na kami sa mga teknolohikal na produkto ng enterprise sa mga microservice at lumipat sa open source o ganap na bukas na mga teknolohiya. Inaabandona namin ang mga database at lumipat sa kung ano ang mas epektibo para sa amin sa modelong ito. Hindi na namin kailangan ang mga teknolohiya ng Oracle.
Nagsimula kami bilang isang serbisyo, nang hindi iniisip kung gaano namin kailangan ang isang cache, kung ano ang aming gagawin kapag walang koneksyon sa isang microservice, ngunit kailangan ang data, atbp. Ngayon kami ay bumubuo ng isang platform upang ang arkitektura ay mailarawan hindi sa wika ng mga serbisyo, at sa wika ng negosyo, dalhin ang lohika ng negosyo sa susunod na antas kapag nagsimula tayong magsalita sa mga salita. Ngayon natuto na kaming magsalita sa mga liham, at ang susunod na antas ay kapag ang mga serbisyo ay kokolektahin sa ilang uri ng pinagsama-samang, kapag ito ay isang salita na - halimbawa, isang buong card ng produkto. Ito ay binuo mula sa mga microservice, ngunit ito ay isang API na binuo sa ibabaw nito.
Napakahalaga ng kaligtasan. Sa sandaling magsimula kang maging accessible at mayroon kang serbisyo kung saan makakakuha ka ng maraming kawili-wiling bagay, at napakabilis, sa isang segundo, pagkatapos ay mayroong pagnanais na makuha ito sa hindi pinaka-secure na paraan. Upang makalayo dito, kinailangan naming baguhin ang mga diskarte sa pagsubok at pagsubaybay. Kinailangan naming baguhin ang koponan, ang istraktura ng pamamahala ng paghahatid, CI/CD.
Ito ay isang ebolusyon - tulad ng sa mga telepono, mas mabilis lang: una ay may mga push-button na telepono, pagkatapos ay lumitaw ang mga smartphone. Isinulat at muling idisenyo nila ang produkto dahil may ibang pangangailangan ang merkado. Ganito tayo umuunlad: unang baitang, ikasampung baitang, trabaho.
Sa paulit-ulit, may inilatag bawat taon mula sa punto ng view ng teknolohiya, iba pa mula sa punto ng view ng backlog at mga pangangailangan. Ikinonekta namin ang isang bagay sa isa pa. Gumagastos ang team ng 20% ββsa teknikal na utang at teknikal na suporta para sa team, 80% sa entity ng negosyo. At kumikilos kami nang may pag-unawa kung bakit namin ito ginagawa, kung bakit namin ginagawa ang mga teknolohikal na pagpapabuti na ito, kung ano ang hahantong sa mga ito. Tulad niyan.
Dmitriy:
Malamig. Ano ang nasa MegaFon?
Alexander:
Ang pangunahing hamon nang dumating kami sa mga microservice ay hindi mahulog sa kaguluhan. Ang opisina ng arkitektura ng MegaFon ay agad na sumali sa amin, kahit na naging isang initiator at driver - ngayon mayroon kaming isang napakalakas na arkitektura. Ang kanyang gawain ay upang maunawaan kung anong target na modelo ang pupuntahan natin at kung anong mga teknolohiya ang kailangang ma-pilot. Sa arkitektura, kami mismo ang nagsagawa ng mga piloto na ito.
Ang susunod na tanong ay: "Kung gayon, paano pagsasamantalahan ang lahat ng ito?" At isa pa: "Paano masisiguro ang malinaw na pakikipag-ugnayan sa pagitan ng mga microservice?" Tinulungan kami ng service mesh na sagutin ang huling tanong. Nag-pilot kami sa Istio at nagustuhan ang mga resulta. Ngayon ay nasa yugto na tayo ng paglunsad sa mga produktibong sona. Mayroon kaming positibong saloobin sa lahat ng mga hamon - ang katotohanan na kailangan naming patuloy na baguhin ang stack, matuto ng bago. Kami ay interesado sa pagbuo, hindi pagsasamantala sa mga lumang solusyon.
Dmitriy:
Mga gintong salita! Ang ganitong mga hamon ay nagpapanatili sa koponan at negosyo sa kanilang mga daliri at lumikha ng hinaharap. Lumikha ang GDPR ng mga punong opisyal ng proteksyon ng data, at ang mga kasalukuyang hamon ay lumikha ng mga punong microservice at mga opisyal ng arkitektura. At ito ay nakalulugod.
Marami kaming napag-usapan. Ang pangunahing bagay ay ang isang mahusay na disenyo ng mga microservice at ang arkitektura mismo ay nagbibigay-daan sa iyo upang maiwasan ang maraming mga pagkakamali. Siyempre, ang proseso ay umuulit at ebolusyonaryo, ngunit ito ang hinaharap.
Salamat sa lahat ng kalahok, salamat kina Sergei at Alexander!
Mga tanong mula sa madla
Tanong mula sa madla (1):
Sergey, paano nagbago ang pamamahala ng IT sa iyong kumpanya? Naiintindihan ko na kapag mayroong isang malaking stack ng ilang mga sistema, kung paano ito pinamamahalaan ay isang medyo malinaw at lohikal na proseso. Paano mo muling binuo ang pamamahala ng bahagi ng IT pagkatapos ng napakalaking bilang ng mga microservice ay naisama sa maikling panahon?
Sergey:
Sumasang-ayon ako sa aking kasamahan na ang arkitektura ay napakahalaga bilang isang driver ng pagbabago. Nagsimula kami sa pagkakaroon ng architectural division. Ang mga arkitekto ay sabay-sabay na may-ari ng pamamahagi ng functionality at ang mga kinakailangan para sa kung paano ito lilitaw sa landscape. Kaya nagsisilbi rin silang mga tagapag-ugnay ng mga pagbabagong ito. Bilang resulta, may mga partikular na pagbabago sa isang partikular na proseso ng paghahatid noong gumawa kami ng CI/CD platform.
Ngunit ang pamantayan, pangunahing mga prinsipyo ng pag-unlad, pagtatasa ng negosyo, pagsubok at pag-unlad ay hindi nakansela. Nagdagdag lang kami ng bilis. Noong nakaraan, ang cycle ay tumagal nang labis, ang pag-install sa mga kapaligiran ng pagsubok ay tumagal ng higit pa. Ngayon, nakikita ng negosyo ang benepisyo at sinabing: "Bakit hindi natin magawa ang pareho sa ibang mga lugar?"
Parang, sa mabuting paraan, isang iniksyon sa anyo ng isang bakuna na nagpakita: magagawa mo ito sa ganitong paraan, ngunit magagawa mo ito sa ibang paraan. Siyempre, may problema sa tauhan, sa kakayahan, sa kaalaman, sa paglaban.
Tanong mula sa madla (2):
Sinasabi ng mga kritiko ng arkitektura ng microservice na mahirap ang pagsubok at pag-unlad. Ito ay lohikal kung saan nagiging kumplikado ang mga bagay. Anong mga hamon ang hinarap ng iyong pangkat at paano mo ito nalampasan? Tanong para sa lahat.
Alexander:
May mga paghihirap kapag lumipat mula sa mga microservice patungo sa isang platform, ngunit malulutas ang mga ito.
Halimbawa, gumagawa kami ng isang produkto na binubuo ng 5-7 microservice. Kailangan naming magbigay ng mga pagsubok sa pagsasama-sama sa buong microservices stack upang bigyan ang berdeng ilaw upang lumipat sa master branch. Hindi na bago sa amin ang gawaing ito: matagal na naming ginagawa ito sa BSS, nang bigyan kami ng vendor ng mga naipadala nang solusyon.
At ang aming problema ay nasa maliit na koponan lamang. Isang QA engineer ang kailangan para sa isang conditional na produkto. At kaya, nagpapadala kami ng produkto ng 5-7 microservice, kung saan 2-3 ay maaaring i-develop ng mga third party. Halimbawa, mayroon kaming isang produkto sa pagbuo kung saan lumalahok ang aming vendor ng system sa pagsingil, ang Mail.ru Group at MegaFon R&D. Kailangan nating saklawin ito ng mga pagsubok bago ito ipadala sa produksyon. Ang QA engineer ay nagtatrabaho sa produktong ito sa loob ng isang buwan at kalahati, at ang natitirang bahagi ng koponan ay naiwan nang wala ang kanyang suporta.
Ang pagiging kumplikado na ito ay sanhi lamang ng pag-scale. Nauunawaan namin na ang mga microservice ay hindi maaaring umiral sa isang vacuum; ang ganap na paghihiwalay ay hindi umiiral. Kapag nagpapalit ng isang serbisyo, palagi naming sinusubukang panatilihin ang kontrata ng API. Kung may nagbago sa ilalim ng hood, mananatili ang front service. Kung nakamamatay ang mga pagbabago, magaganap ang ilang uri ng pagbabagong-anyo ng arkitektura at lumipat tayo sa isang ganap na naiibang metamodel ng data, na ganap na hindi tugma - pagkatapos ay pag-uusapan natin ang paglitaw ng detalye ng serbisyo ng v2 na API. Sinusuportahan namin ang una at pangalawang bersyon nang sabay-sabay, at pagkatapos lumipat ang lahat ng mga consumer sa pangalawang bersyon, isasara lang namin ang una.
Sergey:
gusto kong idagdag. Lubos akong sumasang-ayon tungkol sa mga komplikasyon - nangyayari ang mga ito. Ang tanawin ay nagiging mas kumplikado, at ang mga gastos sa overhead ay tumataas, lalo na para sa pagsubok. Paano haharapin ito: lumipat sa awtomatikong pagsubok. Oo, kakailanganin mong mamuhunan din sa pagsulat ng mga autotest at unit test. Upang ang mga developer ay hindi makapag-commit nang hindi pumasa sa pagsubok, hindi nila mababago ang code. Para kahit na ang push button ay hindi gumana nang walang autotest, unit test.
Mahalagang mapanatili ang dating functionality, at ito ay karagdagang overhead. Kung muling isusulat mo ang isang teknolohiya sa isa pang protocol, pagkatapos ay isusulat mo itong muli hanggang sa ganap mong isara ang lahat.
Minsan hindi namin sinasadya ang end-to-end na pagsubok, dahil ayaw naming ihinto ang pag-unlad, bagama't mayroon din kaming sunod-sunod na bagay. Ang tanawin ay napakalaki, kumplikado, mayroong maraming mga sistema. Minsan mga stub lang ito - oo, ibinababa mo ang margin ng kaligtasan, mas maraming panganib ang lalabas. Ngunit sa parehong oras ay naglalabas ka ng supply.
Alexander:
Oo, binibigyang-daan ka ng mga autotest at unit test na lumikha ng de-kalidad na serbisyo. Kami ay para sa isang pipeline na hindi maipapasa nang walang mga pagsubok sa unit at integration. Kadalasan kailangan nating i-drag ang mga emulator at komersyal na sistema sa mga test zone at development environment, dahil hindi lahat ng system ay maaaring ilagay sa mga test zone. Bukod dito, hindi lang sila nababasa - bumubuo kami ng ganap na tugon mula sa system. Isa itong seryosong bahagi ng pagtatrabaho sa mga microservice, at namumuhunan din kami dito. Kung wala ito, magkakaroon ng kaguluhan.
Tanong mula sa madla (3):
Sa pagkakaintindi ko, ang mga microservice sa simula ay lumago mula sa isang hiwalay na koponan at ngayon ay umiiral sa modelong ito. Ano ang mga kalamangan at kahinaan nito?
Mayroon lang tayong katulad na kuwento: lumitaw ang isang uri ng pabrika ng microservices. Ngayon kami ay may konsepto na dumating sa punto na pinapalawak namin ang diskarte na ito sa produksyon sa pamamagitan ng mga stream at sa pamamagitan ng mga sistema. Sa madaling salita, lumalayo tayo sa sentralisadong pag-unlad ng mga microservice, mga modelo ng microservice, at nagiging mas malapit sa mga system.
Alinsunod dito, ang aming operasyon ay napupunta din sa mga system, iyon ay, desentralisado namin ang paksang ito. Ano ang iyong diskarte at ano ang iyong target na kuwento?
Alexander:
Inalis mo ang pangalang "pabrika ng microservice" mula mismo sa iyong bibig - gusto din naming palakihin. Una, iisa lang talaga ang team namin ngayon. Gusto naming ibigay ang lahat ng development team na mayroon ang MegaFon ng pagkakataong magtrabaho sa isang karaniwang ecosystem. Hindi namin gustong ganap na sakupin ang lahat ng pagpapagana ng pag-unlad na mayroon kami ngayon. Ang lokal na gawain ay sukatin, ang pandaigdigang gawain ay pangunahan ang pag-unlad sa lahat ng mga koponan sa layer ng microservice.
Sergey:
Sasabihin ko sa iyo ang landas na ating tinahak. Nagsimula talaga kaming magtrabaho bilang isang koponan, ngunit ngayon hindi kami nag-iisa. Ako ay isang tagapagtaguyod ng mga sumusunod: dapat mayroong may-ari ng proseso. Kailangan ng isang tao na maunawaan, pamahalaan, kontrolin at buuin ang proseso ng pagbuo ng mga microservice. Dapat siyang nagmamay-ari ng mga mapagkukunan at makisali sa pamamahala ng mapagkukunan.
Ang mga mapagkukunang ito, na nakakaalam ng mga teknolohiya, mga detalye at nakakaunawa kung paano bumuo ng mga microservice, ay matatagpuan sa mga pangkat ng produkto. Mayroon kaming halo kung saan ang mga tao mula sa microservice platform ay nasa pangkat ng produkto na gumagawa ng mobile application. Naroon sila, ngunit nagtatrabaho sila ayon sa proseso ng departamento ng pamamahala ng platform ng microservice kasama ang kanilang tagapamahala ng pag-unlad. Sa loob ng dibisyong ito ay may hiwalay na pangkat na tumatalakay sa teknolohiya. Iyon ay, pinaghalo namin ang isang karaniwang pool ng mga mapagkukunan sa aming sarili at hinahati ang mga ito, na nagbibigay sa kanila sa mga koponan.
Kasabay nito, ang proseso ay nananatiling pangkalahatan, kinokontrol, nagpapatuloy ito ayon sa pangkalahatang mga teknolohikal na prinsipyo, na may pagsubok sa yunit at iba pa - lahat ng bagay na itinayo sa itaas. Maaaring may mga column sa anyo ng mga mapagkukunang nakolekta mula sa iba't ibang departamento ng diskarte sa produkto.
Alexander:
Sergey, ikaw talaga ang may-ari ng proseso, tama? Ibinahagi ba ang backlog ng gawain? Sino ang may pananagutan sa pamamahagi nito?
Sergey:
Look: eto na naman ang timpla. Mayroong backlog na nabuo batay sa mga pagpapabuti ng teknolohiya - ito ay isang kuwento. Mayroong backlog, na nabuo mula sa mga proyekto, at mayroong backlog mula sa mga produkto. Ngunit ang pagkakasunud-sunod ng pagpapakilala sa bawat isa sa mga produkto ng serbisyo o ang paglikha ng serbisyong ito ay binuo ng isang espesyalista sa produkto. Wala siya sa IT directorate; espesyal siyang inalis dito. Ngunit ang aking mga tao ay tiyak na nagtatrabaho ayon sa parehong proseso.
Ang may-ari ng backlog sa iba't ibang direksyon - ang backlog ng mga pagbabago - ay iba't ibang tao. Ang koneksyon ng mga teknolohikal na serbisyo, ang kanilang prinsipyo sa pag-aayos - lahat ng ito ay nasa IT. Pagmamay-ari ko rin ang platform at ang mga mapagkukunan. Sa itaas ay kung ano ang tungkol sa backlog at functional na mga pagbabago, at ang arkitektura sa ganitong kahulugan.
Sabihin nating sinabi ng isang negosyo: "Gusto namin ang function na ito, gusto naming gumawa ng bagong produkto - muling gumawa ng loan." Sagot namin: "Oo, uulitin namin ito." Sinasabi ng mga arkitekto: "Isipin natin: saan tayo magsusulat ng mga microservice sa utang at paano natin ito gagawin?" Pagkatapos ay hinahati namin ito sa mga proyekto, produkto o isang stack ng teknolohiya, inilalagay ito sa mga koponan at ipinapatupad ito. Nakagawa ka na ba ng isang produkto sa loob at nagpasya na gumamit ng mga microservice sa produktong ito? Sinasabi namin: "Ngayon ang mga legacy system na mayroon kami, o mga front-line system, ay dapat lumipat sa mga microservice na ito." Sinabi ng mga arkitekto: "Kaya: sa teknolohikal na backlog sa loob ng mga produktong front-line - ang paglipat sa mga microservice. Pumunta". At nauunawaan ng mga espesyalista sa produkto o may-ari ng negosyo kung gaano karaming kapasidad ang inilalaan, kailan ito gagawin at bakit.
Ang pagtatapos ng talakayan, ngunit hindi lahat
Ang mailto:CLOUD conference ay inayos .
Gumagawa din kami ng iba pang mga kaganapan - hal. @Kubernetes Meetup, kung saan palagi kaming naghahanap ng mahuhusay na tagapagsalita:
- Sundan ang @Kubernetes at iba pang balita sa @Meetup sa aming Telegram channel
- Interesado sa pagsasalita sa isa sa mga @Meetups? Mag-iwan ng kahilingan para sa
Pinagmulan: www.habr.com