Apirilaren 25ean, Mail.ru Taldeko hodeiei eta inguruan hitzaldi bat egin genuen - . Nabarmen batzuk:
- Nagusia — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center eta Yandex.Cloud-ek gure hodeiko merkatuaren eta haien zerbitzuen berezitasunei buruz hitz egin zuten;
- Bitrix24ko lankideek nola egin zuten kontatu zuten ;
- Leroy Merlin, Otkritie, Burger King eta Schneider Electricek interesgarriak eskaini zituzten — Zein zeregin ezartzen dituen bere negozioak ITrako eta zein teknologiak, hodeikoenak barne, itxaropentsuenak direla ikusten duten.
Mailto:CLOUD konferentziako bideo guztiak ikus ditzakezu , eta hemen irakur dezakezu nola joan den mikrozerbitzuei buruzko eztabaida. Alexander Deulin, MegaFon negozio sistemen ikerketa eta garapen zentroko buruak eta Sergey Sergeev, M.Video-Eldorado taldeko informazio teknologien zuzendariak, monolitoak kentzeko kasu arrakastatsuak partekatu zituzten. IT estrategiari, prozesuei eta baita HRari lotutako gaiei buruz ere eztabaidatu dugu.
Panelkideak
- Sergey Sergeev, Taldeko CIO "M.Video-Eldorado";
- Alexander Deulin, enpresa sistemen ikerketa eta garapenerako zentroko burua MegaFon;
- Moderatzailea - Dmitri Lazarenko, PaaS zuzendaritzako burua Mail.ru Cloud Solutions.
Alexander Deulin-en hitzaldiaren ostean berarekin bat egiten du eztabaidarako M.Video-Eldoradoko Sergey Sergeev eta Dmitry Lazarenko, Mail.ru Cloud Solutions eztabaida moderatzailea.
Jarraian eztabaidaren transkripzioa prestatu dizuegu, baina bideoa ere ikus dezakezu:
Mikrozerbitzuetarako trantsizioa merkatuaren beharrei erantzuna da
Dmitriy:
Mikrozerbitzuetara migratzeko esperientzia arrakastatsurik izan al duzu? Eta oro har: non ikusten duzu negozio onurarik handiena mikrozerbitzuak erabiltzeari edo monolitoetatik mikrozerbitzuetara pasatzeak?
Sergey:
Dagoeneko mikrozerbitzuetarako trantsizioan bidea egin dugu eta hiru urte baino gehiago daramatzagu ikuspegi hau erabiltzen. Mikrozerbitzuen beharra justifikatzen zuen lehen beharra frontend-eko hainbat produktu back officerekin bateratze amaigabea izan zen. Eta aldi bakoitzean integrazio eta garapen osagarriak egitera behartuta egon ginen, zerbitzu honen edo bestearen funtzionamendurako gure arauak ezarriz.
Noizbait, gure sistemen funtzionamendua eta funtzionalitateen irteera azkartu behar genituela konturatu ginen. Momentu horretan, dagoeneko merkatuan zeuden mikrozerbitzuak eta mikrozerbitzuen ikuspegia bezalako kontzeptuak, eta probatzea erabaki genuen. Hau 2016an hasi zen. Ondoren, plataforma jarri zen eta lehen 10 zerbitzuak aparteko talde batek ezarri zituen.
Lehen zerbitzuetako bat, gehien kargatu zena, prezioak kalkulatzeko zerbitzua izan zen. Edozein kanalera etortzen zaren bakoitzean, M.Video-Eldorado enpresa taldera, izan webgunera edo txikizkako dendara, han produktu bat hautatu, prezioa webgunean edo “Saskian” ikusi, kostua automatikoki da. zerbitzu batek kalkulatzen du. Zergatik da beharrezkoa: honen aurretik, sistema bakoitzak bere printzipioak zituen sustapenekin lan egiteko - deskontuekin eta abarrekin. Gure back office-ak prezioak kudeatzen ditu; deskontu funtzionaltasuna beste sistema batean ezartzen da. Hau zentralizatu eta zerbitzu berezi eta bereizgarri bat sortu behar zen, hori gauzatzeko aukera emango zigun negozio-prozesu baten moduan. Gutxi gora behera horrela hasi ginen.
Lehen emaitzen balioa oso handia izan zen. Lehenik eta behin, bereizita eta modu bateratuan lan egiteko aukera ematen duten entitate bereizgarriak sortu ahal izan ditugu. Bigarrenik, jabetza kostua murriztu dugu sistema gehiagorekin integratzeari dagokionez.
Azken hiru urteetan, lehen lerroko hiru sistema gehitu ditugu. Zaila zen haiek mantentzea enpresak ordaindu zezakeen baliabide kopuru berarekin. Hori dela eta, saltoki berriak bilatzea sortu zen, merkatuari azkartasunari, barne kostuei eta eraginkortasunari dagokionez erantzunez.
Nola neurtu mikrozerbitzuetara migratzearen arrakasta
Dmitriy:
Nola zehazten da mikrozerbitzuetara migratzeko arrakasta? Zein zen “aurretik” enpresa bakoitzean? Zein neurri erabili zenuen trantsizioaren arrakasta zehazteko, eta nork zehaztu zuen benetan?
Sergey:
Lehenik eta behin, IT barruan jaio zen gaitzaile gisa - gaitasun berriak "desblokeatzen". Dena azkarrago egin beharra genuen nahiko diru berdinagatik, merkatuko erronkei erantzunez. Orain arrakasta sistema ezberdinek berrerabilitako zerbitzu kopuruan adierazten da, prozesuen arteko bateratzean. Orain da, baina momentu horretan plataforma bat sortzeko eta hau egin dezakegun hipotesia berresteko aukera izan zen, eragina emango du eta negozio kasua kalkulatuko du.
Alexander:
Arrakasta barne-sentimendu bat da. Enpresek beti nahi dute gehiago, eta gure atzerapenaren sakontasuna arrakastaren froga da. Hala iruditzen zait.
Sergey:
Bai ados nago. Hiru urtean, dagoeneko berrehun zerbitzu eta atzerapen baino gehiago ditugu. Talde barruan baliabideen beharra hazten ari da, urtero %30. Jendeak sentitu zuelako gertatzen da hau: azkarragoa da, ezberdina da, teknologia desberdinak daude, hau guztia garatzen ari da.
Mikrozerbitzuak etorriko dira, baina muina geratuko da
Dmitriy:
Amaigabeko prozesu bat bezalakoa da, non garapenean inbertitzen duzun. Enpresentzako mikrozerbitzuetarako trantsizioa amaitu al da dagoeneko edo ez?
Sergey:
Oso erraza da erantzutea. Zer iruditzen zaizu: telefonoak ordezkatzea prozesu amaigabea da? Guk urtero erosten ditugu telefonoak. Eta hona hemen: abiaduraren beharra dagoen bitartean, merkatura egokitzeko, aldaketa batzuk beharko dira. Horrek ez du esan nahi gauza estandarrak alde batera uzten ditugunik.
Baina ezin dugu dena estali eta berregin aldi berean. Lehen zeuden integrazio-zerbitzu estandarrak eta tradizionalak ditugu: enpresa-autobusak eta abar. Baina atzerapena dago, eta beharra ere badago. Mugikorretarako aplikazioen kopurua eta haien funtzionaltasuna gero eta handiagoa da. Aldi berean, inork ez du esaten %30 diru gehiago emango dizutenik. Hau da, beti daude beharrak alde batetik, eta eraginkortasunaren bilaketa bestetik.
Dmitriy:
Bizitza sasoi onean dago. (Barreak)
Alexander:
Oro har, bai. Ez dugu ikuspegi iraultzailerik paisaiari muina kentzeko. Lan sistematikoa egiten ari dira sistemak deskonposatzeko, mikrozerbitzuen arkitekturarekin koherenteagoak izan daitezen, sistemek elkarrengan duten eragina murrizteko.
Baina oinarrizko zatia mantentzeko asmoa dugu, operadorearen panoraman beti egongo baitira erosten ditugun plataforma batzuk. Berriz ere, oreka osasuntsu bat behar dugu: ez dugu presarik egin behar muina mozten. Sistemak elkarren ondoan jartzen ditugu, eta orain ikusten da dagoeneko oinarrizko zati askoren gainean gaudela. Gainera, funtzionaltasuna garatuz, gure komunikazio zerbitzuekin lan egiten duten kanal guztietarako beharrezko irudikapenak sortzen ditugu.
Nola saldu mikrozerbitzuak enpresei
Dmitriy:
Interesatuta nago ere - aldatu ez direnentzat, baina planifikatzen ari direnentzat: zein erraza izan zen ideia hau negozioei saltzea eta abentura bat al zen, inbertsio proiektu bat? Edo estrategia kontzientea zen: orain mikrozerbitzuetara goaz eta kitto, ezerk ez gaitu geldituko. Nola izan zen zuretzat?
Sergey:
Ez genuen planteamendu bat saltzen, negozio onura baizik. Arazo bat zegoen negozioetan, eta konpontzen saiatu ginen. Momentu horretan, kanal ezberdinek prezioak kalkulatzeko printzipio desberdinak erabiltzen zituztela adierazi zen, promozioetarako, promozioetarako eta abar bereizita. Zaila zen mantentzea, akatsak gertatu ziren eta bezeroen kexak entzun genituen. Hau da, arazo baten irtenbidea saltzen ari ginen, baina plataforma bat sortzeko dirua behar genuela etorri ginen. Eta negozio kasu bat erakutsi zuten inbertsioaren lehen fasearen adibidea erabiliz: nola jarraituko dugun berreskuratzen eta horrek zer egiteko aukera emango digu.
Dmitriy:
Lehen etapako denbora nolabait grabatu duzu?
Sergey:
Bai ziur. 6 hilabete esleitu genituen nukleoa plataforma gisa sortzeko eta pilotua probatzeko. Denbora horretan, pilotua patinatzeko plataforma bat sortzen saiatu ginen. Orduan hipotesia baieztatu zen, eta funtzionatzen duenez, jarraitu dezakegula esan nahi du. Taldea errepikatzen eta sendotzen hasi ziren; hori egiten duen zati bereizi batera eraman zuten.
Ondoren, negozio-beharretan, aukeretan, baliabideen erabilgarritasunean eta gaur egun lanean dagoen guztian oinarritutako lan sistematikoa dator.
Dmitriy:
ADOS. Alexander, zer diozu?
Alexander:
Gure mikrozerbitzuak “itsasoaren aparretik” jaio ziren, baliabideak aurrezteagatik, zerbitzariaren ahalmenaren eta talde barruan indarrak birbanatzearen ondoriozko hondarrak direla eta. Hasieran, ez genion proiektu hau enpresari saldu. Proiektu bat izan zen, non biok ikertu eta horren arabera garatu genuen. 2018. urtearen hasieran hasi ginen eta arlo hau ilusioz garatu genuen. Salmentak hasi berri dira eta prozesuan gaude.
Dmitriy:
Gertatzen al da negozio batek Google bezalako gauzak egiteko aukera ematen dizula, astean doan egun batean? Ba al duzu halako norabiderik?
Alexander:
Ikerketarekin batera, negozio-arazoei ere aurre egin diegu, beraz, gure mikrozerbitzu guztiak negozio-arazoetarako irtenbideak dira. Hasieran soilik harpidedunen oinarriaren zati txiki bat hartzen zuten mikrozerbitzuak eraiki genituen, eta orain ia produktu enblematiko guztietan gaude.
Eta inpaktu materiala argi dago jada: jada zenbatu gaitezke, produktuen abiarazteen abiadura eta galdutako diru-sarrerak kalkulatu daitezke bide zaharra jarraitu bagenu. Honen gainean eraikitzen ari gara kasua.
Mikrozerbitzuak: hype ala beharra?
Dmitriy:
Zenbakiak zenbakiak dira. Eta diru sarrerak edo aurreztutako dirua oso garrantzitsua da. Eta beste aldera begiratuz gero? Badirudi mikrozerbitzuak joera, hype bat direla eta enpresa askok abusatzen ari direla? Zein argi bereizten dituzu mikrozerbitzuetara itzultzen duzuna eta egiten ez duzuna? Orain ondarea bada, oraindik ere ondarea izango duzu 5 urte barru? Zein adina izango dute M.Video-Eldorado eta MegaFon-en lan egiten duten informazio sistemek 5 urte barru? Hamar urteko, hamabost urteko informazio sistemak egongo dira ala belaunaldi berri bat izango da? Nola ikusten duzu hau?
Sergey:
Oso urrun pentsatzea zaila dela iruditzen zait. Atzera begiratzen badugu, nork imajinatu zuen teknologia-merkatua horrela garatuko zela, ikaskuntza automatikoa eta erabiltzaileak aurpegi bidez identifikatzea barne? Baina datozen urteei erreparatuz gero, iruditzen zait oinarrizko sistemak, enpresetako ERP mailako sistemak, denbora luzez lanean ari direla.
Gure enpresek 25 urte dituzte, eta ERP klasikoa oso sakona dute sistemen panoraman. Argi dago hortik pieza batzuk ateratzen eta mikrozerbitzuetan batzen saiatzen ari garela, baina muina geratuko da. Orain zaila egiten zait imajinatzea oinarrizko sistema guztiak ordezkatuko ditugula eta azkar sistema berrien beste alde argira joango garela.
Bezeroarengandik eta kontsumitzaileengandik hurbilago dagoen guztia negozio onura eta balio handiena dagoen tokian dagoela onartzen dut, non moldagarritasuna eta abiaduran zentratu, aldaketan, "saiatu, bertan behera utzi, berrerabili, beste zerbait egin" dagoenean. behar “—hor aldatuko da paisaia. Eta kutxako produktuak ez dira oso ondo sartzen. Guk behintzat ez dugu ikusten. Irtenbide errazenak eta errazenak behar dira bertan.
Garapen hau ikusten dugu:
- oinarrizko informazio-sistemak (gehienetan back office);
- erdiko geruzek mikrozerbitzuen moduan lotzen dute nukleoa, agregatu, cache bat sortzen dute eta abar;
- lehen lerroko sistemak kontsumitzaileari zuzenduta daude;
- orokorrean merkatuetan, beste sistema batzuetan eta ekosistemetan integratuta dagoen integrazio-geruza. Geruza hau ahalik eta arinena da, sinplea eta negozio-logika minimo bat dauka.
Baina, aldi berean, printzipio zaharrak erabiltzen jarraitzearen aldekoa naiz, egoki erabiltzen badira.
Demagun enpresa-sistema klasiko bat duzula. Saltzaile baten paisaian dago eta elkarrekin lan egiten duten bi moduluz osatuta dago. Integrazio interfaze estandarra ere badago. Zergatik berregin eta mikrozerbitzu bat ekarri hara?
Baina back officen 5 modulu daudenean, eta horietatik informazio zatiak negozio prozesu batean biltzen direnean, 8-10 lehen lerroko sistemek erabiltzen dutenean, onura berehala nabaritzen da. Bost back-office sistemetatik hartu eta negozio-prozesura bideratuta dagoen zerbitzu bat sortzen duzu, isolatua. Egin zerbitzua teknologikoki aurreratua, informazioa cachean gorde dezan eta akatsekiko tolerantzia izan dezan, eta dokumentuekin edo negozio-entitateekin ere funtziona dezan. Eta printzipio bakar baten arabera integratzen duzu lehen lerroko produktu guztiekin. Lehen lerroko produktua bertan behera utzi zuten - integrazioa desaktibatu besterik ez zuten egin. Bihar mugikorretarako aplikazio bat idatzi edo webgune txiki bat egin behar duzu eta zati bakarra jarri funtzionalitatean - dena erraza da: eraikitzaile bat bezala muntatu duzu. Garapen gehiago ikusten dut norabide horretan –gure herrian behintzat–.
Alexander:
Sergeyk guztiz deskribatu zuen gure planteamendua, eskerrik asko. Esango dut, zalantzarik gabe, nora ez garen joango: oinarrizko zatira, lineako fakturazioaren gaira. Hau da, balorazioa eta kobratzea, hain zuzen ere, dirua fidagarriki kenduko duen thresher "handi" bat izaten jarraituko du. Eta sistema hau gure agintari arautzaileek ziurtatuta jarraituko dute. Bezeroei begira dagoen beste guztia, noski, mikrozerbitzuak dira.
Dmitriy:
Hemen ziurtagiria istorio bat da. Seguruenik, laguntza gehiago. Laguntza gutxi gastatzen baduzu edo sistemak laguntza eta aldaketarik behar ez badu, hobe da ez ukitzea. Arrazoizko konpromisoa.
Nola garatu mikrozerbitzu fidagarriak
Dmitriy:
Ederki. Baina oraindik interesatzen zait. Orain arrakasta istorio bat kontatzen ari zara: dena ondo zegoen, mikrozerbitzuetara aldatu ginen, ideia negozioari defendatu eta dena atera zen. Baina beste istorio batzuk entzun ditut.
Duela pare bat urte, bankuentzako mikrozerbitzuen plataforma berri bat garatzen bi urte inbertitu zituen Suitzako konpainia batek azkenean itxi zuen proiektua. Erabat erorita. Suitzako milioika franko asko gastatu ziren, eta azkenean taldea sakabanatu egin zen - ez zuen funtzionatu.
Antzeko istorioak izan al dituzu? Zailtasunik egon al zen edo al dago? Esaterako, mikrozerbitzuak eta jarraipena egitea ere buruhaustea da konpainiaren jarduera operatiboetan. Azken finean, osagai kopurua hamar aldiz handitzen da. Nola ikusten duzu, izan al dira arrakastarik gabeko inbertsioen adibiderik hemen? Eta zer aholkatu diezaioke jendeari horrelako arazorik topa ez dezaten?
Alexander:
Arrakastarik gabeko adibideen artean, negozioak lehentasunak aldatu eta proiektuak bertan behera utzi zituzten. Prestakuntza fase onean dagoenean (hain zuzen ere, MVP prest dago), negozioak esan zuen: "Lehentasun berriak ditugu, beste proiektu batera goaz, eta hau ixten ari gara".
Ez dugu huts globalik izan mikrozerbitzuekin. Lasai lo egiten dugu, 24/7 betebehar-txanda dugu BSS [enpresen laguntza-sistema] osoari zerbitzua ematen diona.
Eta beste gauza bat: mikrozerbitzuak alokatzen ditugu kutxako produktuei aplikatzen zaizkien arauen arabera. Arrakastaren gakoa da, lehenik eta behin, mikrozerbitzua ekoizpenerako guztiz prestatuko duen talde bat bildu behar duzula. Garapena bera, baldintzatuta, %40koa da. Gainerakoa analitika, DevSecOps metodologia, integrazio egokiak eta arkitektura egokia da. Aplikazio seguruak eraikitzeko printzipioei arreta berezia jartzen diegu. Informazioaren segurtasuneko ordezkariek proiektu bakoitzean parte hartzen dute bai arkitekturaren plangintza-fasean, bai ezarpen-prozesuan. Era berean, ahultasunen kodea aztertzeko sistemak kudeatzen dituzte.
Demagun gure estaturik gabeko zerbitzuak zabaltzen ditugula - Kubernetesen ditugu. Horri esker, denek lasai lo egiten dute zerbitzuen eskalatze eta igoera automatikoa dela eta, eta betebeharren txandak gorabeherak jasotzen ditu.
Gure mikrozerbitzuen existentzia osoan, gure lineara iritsi diren gorabehera bat edo bi baino ez dira izan. Orain ez dago funtzionamenduarekin arazorik. Guk, noski, ez ditugu 200, 50 bat mikrozerbitzu baizik, baina produktu enblematikoetan erabiltzen dira. Huts egingo balute, gu izango ginateke horren berri ematen lehenak.
Mikrozerbitzuak eta HR
Sergey:
Ados nago nire lankidearekin laguntzarako transferentziari buruz, lana behar bezala antolatu behar dela. Baina, noski, dauden arazoen berri emango dizut.
Lehenik eta behin, teknologia berria da. Hau hype da modu onean, eta hau ulertuko duen eta sor dezakeen espezialista bat aurkitzea erronka handia da. Baliabideen lehia zoroa da, beraz, adituek merezi dute urrez.
Bigarrenik, paisaia batzuk sortu eta gero eta zerbitzu gehiagorekin, etengabe konpondu behar da berrerabilpenaren arazoa. Garatzaileei gustatzen zaien bezala: “Idatz ditzagun gauza interesgarri asko hemen orain...” Horregatik, sistema hazten da eta eraginkortasuna galtzen du diruaren, jabetzaren kostuaren eta abar. Hau da, beharrezkoa da berrerabilpena sistemaren arkitekturan sartzea, zerbitzuak sartzeko eta ondarea arkitektura berri batera transferitzeko bide-orrian txertatzea.
Beste arazo bat -hau bere erara ona bada ere- barne lehia da. "Oh, modako mutil berriak agertu dira hemen, hizkuntza berri bat hitz egiten dute". Pertsonak, noski, desberdinak dira. Badaude Javan idaztera ohituta daudenak, eta Docker eta Kubernetes idazten eta erabiltzen dutenak. Pertsona guztiz desberdinak dira, ezberdin hitz egiten dute, termino desberdinak erabiltzen dituzte eta batzuetan ez dute elkar ulertzen. Praktika partekatzeko gaitasuna edo ezintasuna, ezagutza partekatzea, zentzu honetan ere arazo bat da.
Tira, baliabideak eskalatu. “Ondo, goazen! Eta orain azkarrago, gehiago nahi dugu. Zer, ezin duzu? Ez al da urtean bi aldiz gehiago ematea? Eta zergatik?" Horrelako hazkuntza-minak gauza askotarako, planteamendu askotarako estandarrak dira ziurrenik, eta senti ditzakezu.
Jarraipenari dagokionez. Zerbitzuak edo monitorizazio industrialeko tresnak dagoeneko ikasten ari direla edo Docker eta Kubernetesekin lan egiteko gai direla beste modu ez-estandarran iruditzen zait. Beraz, esate baterako, ez duzu amaitzen 500 Java makina hau guztia exekutatzen ari den, hots, agregatzen da. Baina produktu horiek oraindik heldutasun falta dute; hori pasatu behar dute. Gaia benetan berria da, garatzen jarraituko du.
Dmitriy:
Bai, oso interesgarria. Eta hau HR-ri dagokio. Agian zure HR prozesua eta HR marka pixka bat aldatu dira 3 urte hauetan. Konpetentzia ezberdineko beste pertsona batzuk kontratatzen hasi zinen. Eta ziurrenik alde onak eta txarrak daude. Aurretik, blockchain-a eta datu-zientzia ziren hype, eta horietan espezialistek milioika balio zuten. Orain kostua jaisten ari da, merkatua asetzen ari da eta antzeko joera dago mikrozerbitzuetan.
Sergey:
Bai, erabat.
Alexander:
HR-k galdera hau egiten du: "Non dago zure unicorn arrosa backend eta frontend artean?" HR-k ez du ulertzen zer den mikrozerbitzu bat. Sekretua kontatu genien eta backend-ak dena egiten zuela esan genien, eta ez dagoela unikorniorik. Baina HR aldatzen ari da, azkar ikasten eta oinarrizko IT ezagutzak dituzten pertsonak kontratatzen ari dira.
Mikrozerbitzuen bilakaera
Dmitriy:
Xede-arkitekturari erreparatuz gero, mikrozerbitzuek halako munstro baten itxura dute. Zure bidaiak hainbat urte iraun zituen. Beste batzuek urtebete dute, besteek hiru urte. Aurreikusi al zenituen arazo guztiak, xede-arkitektura, zerbait aldatu al zen? Adibidez, mikrozerbitzuen kasuan, pasabideak eta zerbitzu-sareak orain berriro agertzen ari dira. Hasieran erabili zenituen ala arkitektura bera aldatu zenuen? Baduzu horrelako erronkak?
Sergey:
Dagoeneko hainbat komunikazio protokolo berridatzi ditugu. Hasieran protokolo bat zegoen, orain beste batera aldatu gara. Segurtasuna eta fidagarritasuna areagotzen ditugu. Enpresa teknologiekin hasi ginen - Oracle, Web Logic. Orain mikrozerbitzuetako enpresa-produktu teknologikoetatik urruntzen ari gara eta kode irekiko edo guztiz irekiko teknologiaetara pasatzen ari gara. Datu-baseak alde batera utzi eta eredu honetan guretzat eraginkorrago funtzionatzen duen horretara pasatzen gara. Jada ez dugu Oracle teknologiak behar.
Zerbitzu gisa hasi ginen, besterik gabe, pentsatu gabe zenbat behar genuen cachea, zer egingo genuen mikrozerbitzu batekin konexiorik ez zegoenean, baina datuak behar ziren, etab. Orain plataforma bat garatzen ari gara, arkitektura deskribatu ahal izateko. ez zerbitzuen hizkuntzan, eta negozioen hizkuntzan, negozio-logika hurrengo mailara eraman hitzez hitz egiten hasten garenean. Orain letraz hitz egiten ikasi dugu, eta hurrengo maila da zerbitzuak nolabaiteko agregatu batean bilduko diren, hori dagoeneko hitz bat denean, adibidez, produktu-txartel osoa. Mikrozerbitzuetatik muntatuta dago, baina horren gainean eraikitako API bat da.
Segurtasuna oso garrantzitsua da. Eskuragarri izaten hasi bezain laster eta zerbitzu bat baduzu, zeinaren bidez gauza interesgarri asko lor ditzakezun, eta oso azkar, segundo zati batean, orduan ez da modu seguruenean lortzeko gogoa. Hortik alde egiteko, azterketa eta monitorizazioaren ikuspegiak aldatu behar izan ditugu. Taldea, entrega kudeaketa egitura, CI/CD aldatu behar izan dugu.
Hau bilakaera bat da - telefonoekin bezala, askoz azkarragoa baino ez: lehen sakagailudun telefonoak zeuden, gero smartphoneak agertu ziren. Produktua berridatzi eta birdiseinatu genuen merkatuak beste behar bat zuelako. Honela eboluzionatzen dugu: lehen maila, hamargarren maila, lana.
Iteratiboki, urtean zerbait ezartzen da teknologiaren ikuspuntutik, beste zerbait atzerapenaren eta beharren ikuspegitik. Gauza bat bestearekin lotzen dugu. Taldeak %20 gastatzen du zor teknikoan eta taldearen laguntza teknikoan, %80 enpresa-entitatean. Eta zergatik egiten ari garen, hobekuntza teknologiko horiek zergatik egiten ari garen, zertara eramango duten ulertuta mugitzen gara. Horrelako.
Dmitriy:
Cool. Zer dago MegaFon-en?
Alexander:
Mikrozerbitzuetara heldu ginenean erronka nagusia kaosean ez erortzea zen. MegaFon-en arkitektura bulegoa berehala sartu zen gurekin, nahiz eta hastapen eta gidari bihurtu zen - orain arkitektura oso sendoa dugu. Bere zeregina zer helburu-eredutara goazen eta zein teknologiak pilotatu behar diren ulertzea zen. Arkitekturarekin, guk geuk egin ditugu pilotu hauek.
Hurrengo galdera hau izan zen: "Orduan nola ustiatu hau guztia?" Eta beste bat: "Nola bermatu mikrozerbitzuen arteko interakzio gardena?" Zerbitzu sareak azken galderari erantzuten lagundu digu. Istio pilotatu genuen eta emaitzak gustatu zitzaizkigun. Orain gune produktiboetara zabaltzeko fasean gaude. Erronka guztien aurrean jarrera positiboa dugu: pila etengabe aldatu behar dugula, zerbait berria ikasi. Konponbide zaharrak garatzea interesatzen zaigu, ez ustiatzea.
Dmitriy:
Urrezko hitzak! Halako erronkek taldea eta negozioak bere horretan mantentzen dituzte eta etorkizuna sortzen dute. GDPR-k datuak babesteko arduradun nagusiak sortu zituen, eta egungo erronkek mikrozerbitzu nagusiak eta arkitekturako arduradunak sortzen dituzte. Eta atsegin du.
Asko eztabaidatu genuen. Gauza nagusia da mikrozerbitzuen diseinu onak eta arkitekturak berak akats asko saihesteko aukera ematen duela. Noski, prozesua errepikakorra eta ebolutiboa da, baina etorkizuna da.
Eskerrik asko parte hartzaile guztiei, eskerrik asko Sergei eta Alexanderri!
Entzuleen galderak
Entzuleen galdera (1):
Sergey, nola aldatu da IT kudeaketa zure enpresan? Ulertzen dut hainbat sistemaren pila handi bat dagoenean, nola kudeatzen den prozesu nahiko argia eta logikoa dela. Nola berreraiki duzu IT osagaiaren kudeaketa hain denbora laburrean mikrozerbitzu kopuru handi bat integratu ostean?
Sergey:
Bat nator nire lankidearekin arkitektura oso garrantzitsua dela aldaketaren eragile gisa. Arkitektura dibisio bat edukiz hasi ginen. Arkitektoak dira, aldi berean, funtzionaltasunaren eta paisaian nola agertuko den eskakizunen banaketaren jabeak. Beraz, aldaketa horien koordinatzaile gisa ere jokatzen dute. Ondorioz, banaketa prozesu zehatz batean aldaketa zehatzak izan ziren CI/CD plataforma bat sortu genuenean.
Baina garapenaren, negozioaren analisiaren, probaren eta garapenaren oinarrizko printzipio estandarrak ez dira bertan behera utzi. Abiadura gehitu besterik ez dugu. Aurretik, zikloak hainbeste behar zuen, proba-inguruneetan instalatzeak askoz gehiago behar zuen. Orain enpresek onura ikusten dute eta esaten dute: "Zergatik ezin dugu gauza bera egin beste leku batzuetan?"
Modu onean, txerto moduko injekzioa erakusten zuen: horrela egin dezakezu, baina beste era batera egin dezakezu. Jakina, arazo bat dago pertsonalean, konpetentzetan, ezagutzan, erresistentzian.
Entzuleen galdera (2):
Mikrozerbitzuen arkitekturaren kritikariek diote probak eta garapenak zailak direla. Hau logikoa da, non gauzak konplikatzen diren. Zein erronka izan ditu zure taldeak eta nola gainditu dituzu? Guztiontzako galdera.
Alexander:
Mikrozerbitzuetatik plataforma batera pasatzean zailtasunak daude, baina konpondu daitezke.
Adibidez, 5-7 mikrozerbitzuz osatutako produktu bat egiten ari gara. Integrazio probak eman behar ditugu mikrozerbitzuen pila osoan zehar adar nagusira mugitzeko argi berdea emateko. Zeregin hau ez zen berria guretzat: denbora luzez ari ginen BSSn, saltzaileak jada bidalitako soluzioak eman zizkigunean.
Eta gure arazoa talde txikian bakarrik dago. Baldintzapeko produktu baterako QA ingeniari bat behar da. Beraz, 5-7 mikrozerbitzuko produktu bat bidaltzen dugu, eta horietatik 2-3 hirugarrenek garatu ditzakete. Esate baterako, gure fakturazio sistemaren saltzaileak, Mail.ru Taldeak eta MegaFon I+G-k parte hartzen duten produktu bat dugu garapenean. Hau probekin estali behar dugu ekoizpenera bidali aurretik. QA ingeniariak hilabete eta erdi darama produktu honetan lanean, eta gainerako taldea bere laguntzarik gabe geratu da.
Konplexutasun hori eskalatzeak bakarrik eragiten du. Ulertzen dugu mikrozerbitzuak ezin direla hutsean existitu; erabateko isolamendua ez da existitzen. Zerbitzu bat aldatzean, beti saiatzen gara API kontratua mantentzen. Kanpaiaren azpian zerbait aldatzen bada, aurreko zerbitzua geratzen da. Aldaketak larriak badira, nolabaiteko eraldaketa arkitektonikoa gertatzen da eta datu metaeredu guztiz ezberdin batera mugitzen gara, guztiz bateraezina dena; orduan bakarrik hitz egingo dugu v2 zerbitzuaren APIaren zehaztapena agertzeari buruz. Lehen eta bigarren bertsioak aldi berean onartzen ditugu, eta kontsumitzaile guztiak bigarren bertsiora aldatu ondoren, lehenengoa itxi besterik ez dugu egiten.
Sergey:
gehitu nahi dut. Erabat ados nago konplikazioei buruz - gertatzen dira. Paisaia gero eta konplexuagoa da, eta kostu orokorrak handitzen ari dira, batez ere probetarako. Nola egin horri aurre: proba automatizatuetara aldatu. Bai, gainera inbertitu beharko duzu autotestak eta unitate probak idazten. Beraz, garatzaileek proba gainditu gabe ezin izan zuten konpromisoa hartu, ezin zuten kodea aldatu. Beraz, sakagailuak ere ez du funtzionatuko autotest gabe, unitate proba.
Garrantzitsua da aurreko funtzionaltasuna mantentzea, eta hau gainkostua da. Teknologia bat beste protokolo batean berridazten baduzu, berriro idazten duzu dena guztiz itxi arte.
Batzuetan ez dugu amaierako probarik egiten nahita, ez dugulako garapena gelditu nahi, nahiz eta gauza bat bestearen atzetik ere badugun. Paisaia oso handia da, konplexua, sistema asko daude. Batzuetan zirriborroak besterik ez dira - bai, segurtasun-marjina murrizten duzu, arrisku gehiago agertzen dira. Baina, aldi berean, hornidura askatzen duzu.
Alexander:
Bai, autotestek eta unitate probak kalitate handiko zerbitzu bat sortzeko aukera ematen dute. Unitate eta integrazio probarik gabe gainditu ezin den kanalizazio baten alde gaude. Askotan emuladoreak eta sistema komertzialak proba-eremuetara eta garapen-inguruneetara arrastatu behar izaten ditugu, sistema guztiak ezin baitira proba-eremuetan jarri. Gainera, ez dira bustitzen, sistemaren erantzun osoa sortzen dugu. Mikrozerbitzuekin lan egitearen zati serioa da, eta horretan inbertitzen ari gara ere. Hori gabe, kaosa sortuko da.
Entzuleen galdera (3):
Nik ulertzen dudanez, mikrozerbitzuak hasiera batean talde ezberdin batetik hazi ziren eta orain eredu honetan daude. Zeintzuk dira bere alde onak eta txarrak?
Antzeko istorio bat besterik ez dugu: mikrozerbitzuen fabrika moduko bat sortu zen. Orain kontzeptualki iritsi gara ekoizpenaren ikuspegi hori korronteen eta sistemen arabera zabaltzen ari garela. Beste era batera esanda, mikrozerbitzuen, mikrozerbitzu ereduen garapen zentralizatutik urruntzen ari gara eta sistemetara gero eta hurbilago gaude.
Horren arabera, gure funtzionamendua sistemetara ere doa, hau da, gai hau deszentralizatzen ari gara. Zein da zure ikuspegia eta zein da zure xede-istorioa?
Alexander:
"Mikrozerbitzuen fabrika" izena ahotik kendu zenuen - guk ere eskalatu nahi dugu. Lehenik eta behin, benetan talde bat dugu orain. MegaFonek dituen garapen talde guztiei ekosistema komun batean lan egiteko aukera eskaini nahi diegu. Ez dugu orain ditugun garapen funtzionaltasun guztiak guztiz bereganatu nahi. Tokiko zeregina eskalatzea da, zeregin globala mikrozerbitzuen geruzako talde guztiei garapena eramatea da.
Sergey:
Egin dugun bidea kontatuko dizut. Benetan talde bakarrean hasi ginen lanean, baina orain ez gaude bakarrik. Honen aldekoa naiz: prozesuaren jabe bat egon behar da. Norbaitek mikrozerbitzuen garapen prozesua ulertu, kudeatu, kontrolatu eta eraiki behar du. Baliabideen jabe izan behar du eta baliabideen kudeaketan aritu.
Baliabide hauek, teknologiak, zehaztasunak ezagutzen dituztenak eta mikrozerbitzuak nola eraikitzen ulertzen dituztenak, produktu-taldeetan kokatu daitezke. Nahasketa bat dugu, non mikrozerbitzuen plataformako jendea mugikorretarako aplikazioa egiten duen produktu taldean dauden. Hor daude, baina mikrozerbitzuen plataforma kudeatzeko sailaren prozesuaren arabera lan egiten dute beren garapeneko arduradunarekin. Dibisio honen barruan teknologiaz arduratzen den talde bereizi bat dago. Hau da, baliabide komun bat nahasten ditugu gure artean eta banatzen ditugu, taldeei emanez.
Aldi berean, prozesuak orokorra izaten jarraitzen du, kontrolatua, printzipio teknologiko orokorren arabera egiten du, unitate-probak eta abarrekin - gainean eraikitako guztia. Zutabeak egon daitezke produktuaren ikuspegiaren sail ezberdinetatik jasotako baliabideen moduan.
Alexander:
Sergey, benetan prozesuaren jabea zara, ezta? Zereginen atzerapena partekatzen al da? Nor da bere banaketaren arduraduna?
Sergey:
Begira: hona hemen berriro nahasketa. Hobekuntza teknologikoetan oinarrituta eratzen den atzerapena dago - istorio bat da hau. Atzerapen bat dago, proiektuetatik formulatzen dena, eta produktuen atzerapena dago. Baina zerbitzu-produktu bakoitzean sartzeko sekuentzia edo zerbitzu honen sorrera produktu espezialista batek garatzen du. Ez dago informatika zuzendaritzan;bereziki kendu zuten. Baina nire jendeak prozesu beraren arabera egiten du lan.
Norabide desberdinetako atzerapenaren jabea - aldaketen atzerapena - pertsona desberdinak izango dira. Zerbitzu teknologikoen konexioa, haien antolakuntza-printzipioa - hori guztia informatikan izango da. Plataformaren eta baliabideen jabe naiz. Goialdean atzerapenari eta aldaketa funtzionalei dagokiena dago, eta zentzu honetan arkitektura.
Demagun negozio batek esaten duela: "Funtzio hau nahi dugu, produktu berri bat sortu nahi dugu - mailegu bat birsortu". Erantzuten dugu: "Bai, berriro egingo dugu". Arkitektoek esaten dute: "Pentsa dezagun: maileguan non idatziko ditugu mikrozerbitzuak eta nola egingo ditugu?" Ondoren, proiektuetan, produktuetan edo teknologia-pila batean zatitzen dugu, taldeetan jartzen dugu eta inplementatzen dugu. Produktu bat sortu al duzu barnean eta produktu honetan mikrozerbitzuak erabiltzea erabaki duzu? Esaten dugu: "Orain geneuzkan oinordeko sistemak edo lehen lerroko sistemek mikrozerbitzu horietara aldatu behar dute". Arkitektoek diote: "Beraz: lehen lerroko produktuen barneko atzerapen teknologikoan - mikrozerbitzuetarako trantsizioa. Joan". Eta produktuen espezialistek edo negozioen jabeek ulertzen dute zenbat ahalmen esleitzen den, noiz egingo den eta zergatik.
Eztabaidaren amaiera, baina ez guztiak
Mailto:CLOUD jardunaldia antolatu zen .
Beste ekitaldi batzuk ere egiten ditugu -adib. @Kubernetes Meetup, non beti hizlari bikainen bila gabiltzan:
- Jarraitu @Kubernetes eta @Meetup-en beste albiste batzuk gure Telegram kanalean
- @Meetup-etako batean hitz egitea interesatzen zaizu? Utzi eskaera bat
Iturria: www.habr.com