Op 25 april hawwe wy by Mail.ru Group in konferinsje hâlden oer wolken en om - . In pear hichtepunten:
- It wichtichst - Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center en Yandex.Cloud sprieken oer de spesifiken fan ús wolkmerk en har tsjinsten;
- Kollega's fan Bitrix24 fertelden hoe't se ;
- Leroy Merlin, Otkritie, Burger King en Schneider Electric levere ynteressant - hokker taken har bedriuw stelt foar IT en hokker technologyen, ynklusyf wolken, se sjogge as de meast belofte.
Jo kinne alle fideo's besjen fan 'e mailto:CLOUD-konferinsje , en hjir kinne jo lêze hoe't de diskusje oer mikrotsjinsten gie. Alexander Deulin, haad fan it MegaFon bedriuwsysteemûndersyk en ûntwikkelingssintrum, en Sergey Sergeev, direkteur fan ynformaasjetechnology fan 'e M.Video-Eldorado-groep, dielde har suksesfolle gefallen fan it kwytreitsje fan monoliten. Wy besprutsen ek relatearre problemen fan IT-strategy, prosessen en sels HR.
Panelleden
- Sergey Sergeev, Group CIO "M.Video-Eldorado";
- Alexander Deulin, haad fan it sintrum foar ûndersyk en ûntwikkeling fan saaklike systemen MegaFon;
- Moderator - Dmitry Lazarenko, Haad fan PaaS rjochting Mail.ru Cloud Solutions.
Nei de taspraak fan Alexander Deulin hy wurdt gearfoege foar diskusje troch Sergey Sergeev út M.Video-Eldorado en diskusje moderator Dmitry Lazarenko, Mail.ru Cloud Solutions.
Hjirûnder hawwe wy in transkripsje fan 'e diskusje foar jo taret, mar jo kinne ek de fideo besjen:
De oergong nei mikrotsjinsten is in antwurd op merkferlet
Dmitriy:
Hawwe jo in súksesfolle ûnderfining hân mei migrearjen nei mikrotsjinsten? En yn it algemien: wêr sjogge jo it grutste bedriuwsfoardiel fan it brûken fan mikrotsjinsten of it ferpleatsen fan monoliten nei mikrotsjinsten?
Sergey:
Wy binne al wat wei kommen yn 'e oergong nei mikrotsjinsten en hawwe dizze oanpak al mear as trije jier brûkt. De earste need dy't de needsaak foar mikrotsjinsten rjochtfeardige wie de einleaze yntegraasje fan ferskate front-end produkten mei it back office. En elke kear waarden wy twongen om ekstra yntegraasje en ûntwikkeling te dwaan, it útfieren fan ús eigen regels foar de eksploitaasje fan dizze of dy tsjinst.
Op in stuit realisearre wy dat wy de wurking fan ús systemen en de útfier fan funksjonaliteit moasten fersnelle. Op dat stuit bestiene konsepten as mikrotsjinsten en in oanpak fan mikrotsjinsten al op 'e merke, en wy besletten it te besykjen. Dit begon yn 2016. Doe waard it platfoarm lein en de earste 10 tsjinsten waarden útfierd troch in apart team.
Ien fan 'e earste tsjinsten, de meast swier beladen, wie de tsjinst foar priisberekkening. Elke kear as jo op elk kanaal komme, nei de M.Video-Eldorado-groep fan bedriuwen, of it no in webside of in retailwinkel is, selektearje dêr in produkt, sjoch de priis op 'e webside of yn' e "basket", de kosten binne automatysk berekkene troch ien tsjinst. Wêrom is dit nedich: dêrfoar hie elk systeem syn eigen prinsipes foar it wurkjen mei promoasjes - mei koartingen ensafuorthinne. Us back office behannelet prizen; koartingsfunksjonaliteit wurdt ymplementearre yn in oar systeem. Dit moast sintralisearre wurde en in unike, skiedbere tsjinst kreëarre yn 'e foarm fan in saaklik proses dat ús soe tastean om dit út te fieren. Dat is sa'n bytsje hoe't wy binne begûn.
De wearde fan de earste resultaten wie tige grut. As earste koenen wy skiedbere entiteiten meitsje wêrmei wy apart en op in aggregearre manier kinne wurkje. Twads hawwe wy de kosten fan eigendom ferlege yn termen fan yntegraasje mei mear systemen.
Yn 'e ôfrûne trije jier hawwe wy trije frontline-systemen tafoege. Se wiene dreech te ûnderhâlden mei deselde hoemannichte middels dat it bedriuw koe betelje. Dêrom ûntstie de taak om te sykjen nei nije ferkeappunten, te reagearjen op 'e merk yn termen fan snelheid, yn termen fan ynterne kosten en effisjinsje.
Hoe it sukses te mjitten fan migrearjen nei mikrotsjinsten
Dmitriy:
Hoe wurdt sukses by it migrearjen nei mikrotsjinsten bepaald? Wat wie de "foar" yn elk bedriuw? Hokker metrik hawwe jo brûkt om it sukses fan 'e oergong te bepalen, en wa hat it eins bepaald?
Sergey:
Earst fan alles, it waard berne binnen IT as in ynskeakeler - "ûntsluten" nije mooglikheden. Wy hiene in needsaak om alles flugger te dwaan foar relatyf itselde jild, te reagearjen op merkútdagings. No wurdt sukses útdrukt yn it oantal tsjinsten werbrûkt troch ferskate systemen, ferieniging fan prosessen ûnderinoar. No is it, mar op dat stuit wie it in kâns om in platfoarm te meitsjen en de hypoteze te befestigjen dat wy dit kinne dwaan, it sil in effekt jaan en de saaklike saak berekkenje.
Alexander:
Sukses is earder in ynterne gefoel. Bedriuw wol altyd mear, en de djipte fan ús efterstân is in bewiis fan sukses. It liket my sa.
Sergey:
Ja, ik mei iens. Yn trije jier hawwe wy al mear as twahûndert tsjinsten en efterstân. De needsaak foar middels binnen it team groeit allinich - mei 30% jierliks. Dit bart om't minsken fielden: it is flugger, it is oars, d'r binne ferskate technologyen, dit alles ûntwikkelet.
Mikrotsjinsten sille komme, mar de kearn sil bliuwe
Dmitriy:
It is as in einigjend proses wêryn jo ynvestearje yn ûntwikkeling. Is de oergong nei mikrotsjinsten foar bedriuw al foarby of net?
Sergey:
It is hiel maklik om te antwurdzjen. Wat tinke jo: tillefoans ferfangen is in einleaze proses? Wy sels keapje alle jierren telefoans. En hjir is it: salang't der ferlet is fan snelheid, foar oanpassing oan 'e merk, sille guon feroarings nedich wêze. Dit betsjut net dat wy standert dingen ferlitte.
Mar wy kinne net alles yn ien kear dekke en opnij meitsje. Wy hawwe legacy, standert yntegraasjetsjinsten dy't earder beskikber wiene: bedriuwsbussen ensafuorthinne. Mar der is in efterstân, en der is ek ferlet. It oantal mobile applikaasjes en har funksjonaliteit groeit. Tagelyk seit gjinien dat jo 30% mear jild krije. Dat is, d'r binne altyd behoeften oan 'e iene kant, en in syktocht nei effisjinsje oan' e oare kant.
Dmitriy:
It libben is yn goede foarm. (lacht)
Alexander:
Yn it algemien, ja. Wy hawwe gjin revolúsjonêre oanpakken om it kearnpart út it lânskip te heljen. Systematyske wurk is oan 'e gong om systemen te ûntbinen sadat se mear konsistint binne mei mikroservicearsjitektuer, om de ynfloed fan systemen op elkoar te ferminderjen.
Mar wy binne fan plan it kearndiel te hâlden, om't yn it lânskip fan 'e operator altyd wat platfoarms sille wêze dy't wy keapje. Nochris hawwe wy in sûn lykwicht nedich: wy moatte net haasten om de kearn út te snijen. Wy pleatse de systemen njonkeninoar, en no docht bliken dat wy al boppe op in protte kearndielen binne. Fierder, it ûntwikkeljen fan de funksjonaliteit, meitsje wy de nedige fertsjintwurdigingen foar alle kanalen dy't wurkje mei ús kommunikaasjetsjinsten.
Hoe kinne jo mikrotsjinsten ferkeapje oan bedriuwen
Dmitriy:
Ik bin ek ynteressearre - foar dyjingen dy't net oerstapt hawwe, mar fan plan binne: hoe maklik wie it om dit idee te ferkeapjen oan bedriuw en wie it in aventoer, in ynvestearringsprojekt? Of wie it in bewuste strategy: no geane wy nei mikrotsjinsten en dat is it, neat sil ús stopje. Hoe wie it foar dy?
Sergey:
Wy ferkochten gjin oanpak, mar in saaklik foardiel. D'r wie in probleem yn it bedriuwslibben, en wy besochten it op te lossen. Op dat stuit waard it útdrukt yn it feit dat ferskate kanalen ferskate prinsipes brûkten foar it berekkenjen fan prizen - apart foar promoasjes, foar promoasjes, ensfh. It wie dreech te ûnderhâlden, flaters barde, en wy harke nei klant klachten. Dat is, wy ferkochten in oplossing foar in probleem, mar wy kamen mei it feit dat wy jild nedich wiene om in platfoarm te meitsjen. En se lieten in saaklike saak sjen mei it foarbyld fan 'e earste faze fan ynvestearring: hoe't wy it trochgean sille weromhelje en wat dit ús kin dwaan.
Dmitriy:
Hawwe jo op ien of oare manier de tiid fan 'e earste etappe opnommen?
Sergey:
Ja, wiswier. Wy hawwe 6 moannen tawiisd om de kearn as platfoarm te meitsjen en de pilot te testen. Yn dizze tiid hawwe wy besocht in platfoarm te meitsjen wêrop de piloat reedride. Doe waard de hypoteze befêstige, en om't it wurket, betsjut it dat wy trochgean kinne. Se begûnen it team te replikearjen en te fersterkjen - se ferpleatsen it yn in aparte divyzje dy't dat krekt docht.
Dêrnei komt systematysk wurk basearre op saaklike behoeften, kânsen, beskikberens fan middels en alles wat op it stuit yn 'e wurken is.
Dmitriy:
OK. Alexander, wat sizze jo?
Alexander:
Us mikrotsjinsten binne berne út 'e "skuim fan' e see" - troch it besparjen fan boarnen, troch guon oerbliuwsels yn 'e foarm fan serverkapasiteit en de werferdieling fan krêften binnen it team. Yn it earstoan hawwe wy dit projekt net ferkocht oan bedriuw. Dit wie in projekt wêrby't wy sawol ûndersocht en ûntwikkele hawwe. Wy begûnen oan it begjin fan 2018 en ûntwikkele dizze rjochting gewoan mei entûsjasme. De ferkeap is krekt begûn en wy binne yn it proses.
Dmitriy:
Komt it foar dat in bedriuw jo sokke dingen as Google kinne dwaan - op ien frije dei yn 'e wike? Hawwe jo sa'n rjochting?
Alexander:
Tagelyk mei ûndersyk hawwe wy ek saaklike problemen behannele, sadat al ús mikrotsjinsten oplossingen binne foar saaklike problemen. Allinnich oan it begjin bouden wy mikrotsjinsten dy't in lyts diel fan 'e abonneebasis besloegen, en no binne wy oanwêzich yn hast alle flaggeskipprodukten.
En de materiële ynfloed is al dúdlik - wy kinne al teld wurde, de snelheid fan produktlansearrings en ferlerne ynkomsten kinne wurde rûsd as wy it âlde paad folge hawwe. Dit is wêrop wy de saak bouwe.
Mikrotsjinsten: hype of needsaak?
Dmitriy:
Sifers binne nûmers. En ynkomsten as jild besparre is heul wichtich. Wat as jo nei de oare kant sjogge? It liket derop dat mikrotsjinsten in trend binne, in hype en in protte bedriuwen misbrûke it? Hoe dúdlik ûnderskiede jo tusken wat jo dogge en net oersette nei mikrotsjinsten? As legacy no, sille jo oer 5 jier noch legacy hawwe? Wat sil de leeftyd wêze fan 'e ynformaasjesystemen dy't wurkje by M.Video-Eldorado en MegaFon yn 5 jier? Komme der tsien jier, fyftjin jier âlde ynformaasjesystemen of wurdt it in nije generaasje? Hoe sjogge jo dit?
Sergey:
It liket my ta dat it dreech is om hiel fier fuort te tinken. As wy werom sjogge, wa hat foarsteld dat de technologymerk dizze manier soe ûntwikkelje, ynklusyf masine learen en brûkersidentifikaasje troch gesicht? Mar as jo sjogge nei de kommende jierren, it liket my dat kearnsystemen, enterprise ERP-klasse systemen yn bedriuwen - se hawwe wurke foar in hiel lange tiid.
Us bedriuwen binne kollektyf 25 jier âld, mei klassike ERP heul djip yn it systeemlânskip. It is dúdlik dat wy guon stikken derút nimme en besykje se te aggregearjen yn mikrotsjinsten, mar de kearn sil bliuwe. It is my no dreech foar te stellen dat wy dêr alle kearnsystemen ferfange en gau nei de oare, ljochte kant fan de nije systemen ferhúzje.
Ik bin in foarstanner fan it feit dat alles wat tichter by de klant en konsumint is wêr't de grutste saaklike foardiel en wearde is, wêr't oanpassingsfermogen en fokus op snelheid, op feroaring, op "probearje, annulearje, opnij brûke, wat oars dwaan" binne nedich "- dat is wêr't it lânskip sil feroarje. En doaze produkten passe der net sa goed yn. Wy sjogge it teminsten net. De maklikste, ienfâldichste oplossingen binne dêr nedich.
Wy sjogge dizze ûntwikkeling:
- kearnynformaasjesystemen (meast backoffice);
- middelste lagen yn 'e foarm fan mikroservices ferbine de kearn, aggregearje, meitsje in cache, ensfh.
- frontline systemen binne rjochte op de konsumint;
- in yntegraasjelaach dy't oer it algemien yntegrearre is yn merkplakken, oare systemen en ekosystemen. Dizze laach is sa ljocht mooglik, ienfâldich, en befettet in minimum fan saaklike logika.
Mar tagelyk bin ik in foarstanner om de âlde prinsipes troch te gean as se goed brûkt wurde.
Litte wy sizze dat jo in klassyk bedriuwssysteem hawwe. It leit yn it lânskip fan ien ferkeaper en bestiet út twa modules dy't wurkje mei elkoar. D'r is ek in standert yntegraasje-ynterface. Wêrom it opnij meitsje en dêr in mikroservice bringe?
Mar as d'r 5 modules yn 'e efterkant steane, wêrfan stikken ynformaasje sammele wurde yn in saaklik proses, dat dan brûkt wurdt troch 8-10 frontline-systemen, dan is it foardiel fuortendaliks te merken. Jo nimme út fiif back-office systemen en meitsje in tsjinst, in isolearre ien, dy't rjochte is op it saaklike proses. Meitsje de tsjinst technologysk avansearre - sadat it ynformaasje cache en fouttolerant is, en ek wurket mei dokuminten as saaklike entiteiten. En jo yntegrearje it neffens ien prinsipe mei alle frontline produkten. Se annulearre it frontline-produkt - se skeakelen de yntegraasje gewoan út. Moarn moatte jo in mobile applikaasje skriuwe of in lytse webside meitsje en mar ien diel yn funksjonaliteit sette - alles is ienfâldich: jo hawwe it gearstald as in konstruktor. Ik sjoch mear ûntwikkeling yn dizze rjochting - alteast yn ús lân.
Alexander:
Sergey beskreau ús oanpak folslein, tank. Ik sil gewoan sizze wêr't wy perfoarst net sille gean - nei it kearn diel, nei it ûnderwerp fan online fakturearring. Dat is, beoardieling en opladen bliuwe, yn feite, in "grutte" drompel dy't jild betrouber sil ôfskriuwe. En dit systeem sil fierder wurde sertifisearre troch ús regeljouwingsautoriteiten. Al it oare dat nei kliïnten sjocht, is fansels mikrotsjinsten.
Dmitriy:
Hjir is sertifisearring ien ferhaal. Wierskynlik mear stipe. As jo net folle besteegje oan stipe of it systeem hat gjin stipe en modifikaasje nedich, is it better om it net oan te reitsjen. In ridlik kompromis.
Hoe kinne jo betroubere mikrotsjinsten ûntwikkelje
Dmitriy:
Moai. Mar ik bin noch altyd ynteressearre. No fertelle jo in súksesferhaal: alles wie goed, wy gongen oer nei mikrotsjinsten, ferdigene it idee foar it bedriuw, en alles slagge. Mar ik haw oare ferhalen heard.
In pear jier lyn slute in Switsersk bedriuw dat twa jier ynvestearre hie yn it ûntwikkeljen fan in nij mikroserviceplatfoarm foar banken it projekt. Folslein ynstoart. In protte miljoenen Switserske franken waarden bestege, mar op it lêst waard it team ferspraat - it slagge net.
Hawwe jo ferlykbere ferhalen hân? Wiene of binne der swierrichheden? Bygelyks, it behâld fan mikrotsjinsten en tafersjoch is ek in kopke yn 'e operasjonele aktiviteiten fan it bedriuw. Ommers, it oantal ûnderdielen nimt ta tsientallen kearen. Hoe sjogge jo it, hawwe hjir mislearre foarbylden west fan ynvestearrings? En wat kinne jo minsken advisearje, sadat se sokke problemen net tsjinkomme?
Alexander:
Net-suksesfolle foarbylden omfette bedriuwen dy't prioriteiten feroarje en projekten annulearje. Doe't it bedriuw yn in goed stadium fan reewilligens wie (yn feite is de MVP klear), sei it bedriuw: "Wy hawwe nije prioriteiten, wy geane troch nei in oar projekt, en wy slute dit."
Wy hiene gjin globale mislearrings mei mikrotsjinsten. Wy sliepe rêstich, wy hawwe in 24/7 plicht shift dy't tsjinnet de hiele BSS [bedriuwstipe systeem].
En noch ien ding - wy ferhiere mikrotsjinsten neffens de regels dy't jilde foar produkten yn doazen. De kaai foar sukses is dat jo earst in team moatte gearstalle dat de mikrotsjinst folslein sil tariede op produksje. De ûntwikkeling sels is, betingst, 40%. De rest is analytyk, DevSecOps-metodology, de juste yntegraasjes en de juste arsjitektuer. Wy jouwe spesjaal omtinken oan de prinsipes fan it bouwen fan feilige applikaasjes. Fertsjintwurdigers fan ynformaasjefeiligens dogge mei oan elk projekt sawol yn 'e arsjitektuerplanningsstadium as yn' e ymplemintaasjeproses. Se beheare ek systemen foar it analysearjen fan koade foar kwetsberens.
Litte wy sizze dat wy ús steatleaze tsjinsten ynsette - wy hawwe se yn Kubernetes. Dit lit elkenien rêstich sliepe troch auto-skaalfergrutting en auto-ferheging fan tsjinsten, en de plichtferskowing nimt ynsidinten op.
Yn it hiele bestean fan ús mikrotsjinsten binne d'r mar ien of twa ynsidinten west dy't ús line hawwe berikt. No binne d'r gjin problemen mei operaasje. Wy hawwe fansels net 200, mar sawat 50 mikrotsjinsten, mar se wurde brûkt yn flaggeskipprodukten. As se mislearre, soene wy de earste wêze dy't it witte.
Microservices en HR
Sergey:
Ik bin it mei myn kollega iens oer de oerstap nei stipe - dat it wurk goed organisearre wurde moat. Mar ik sil jo fertelle oer de problemen dy't fansels bestean.
As earste, de technology is nij. Dit is hype op in goede manier, en it finen fan in spesjalist dy't sil begripe en kin meitsje dit is in grutte útdaging. De konkurrinsje foar boarnen is gek, dus saakkundigen binne har gewicht yn goud wurdich.
Twad, mei it oanmeitsjen fan bepaalde lânskippen en in groeiend tal tsjinsten, moat it probleem fan wergebrûk hieltyd oplost wurde. As ûntwikkelders graach dwaan: "Litte wy hjir no in protte nijsgjirrige dingen skriuwe ..." Hjirtroch groeit it systeem en ferliest syn effektiviteit yn termen fan jild, eigendomskosten, ensfh. Dat is, it is nedich om opnij gebrûk te meitsjen yn 'e systeemarsjitektuer, it op te nimmen yn' e roadmap foar it yntrodusearjen fan tsjinsten en it oerdragen fan legacy nei in nije arsjitektuer.
In oar probleem - hoewol dit op syn eigen manier goed is - is ynterne konkurrinsje. "Oh, nije modieuze jonges binne hjir ferskynd, se prate in nije taal." Minsken binne fansels oars. D'r binne dejingen dy't wend binne om te skriuwen yn Java, en dejingen dy't Docker en Kubernetes skriuwe en brûke. Dat binne folslein oare minsken, se prate oars, brûke ferskillende termen en begripe elkoar soms net. It fermogen of ûnfermogen om praktyk te dielen, kennis te dielen, yn dizze sin is ek in probleem.
No, skaalfergrutting fan boarnen. "Geweldich, litte wy gean! En no wolle wy flugger, mear. Wat, kinne jo net? Is it net mooglik om twa kear safolle yn in jier te leverjen? En werom?" Sokke groeipine binne wierskynlik standert foar in protte dingen, in protte oanpak, en jo kinne se fiele.
Oangeande tafersjoch. It liket my dat tsjinsten as ark foar yndustriële tafersjoch al leare of kinne wurkje mei sawol Docker as Kubernetes yn in oare, net-standert modus. Sadat jo bygelyks net komme mei 500 Java-masines dêr't dit alles ûnder rint, nammentlik it aggregearret. Mar dizze produkten hawwe noch gjin folwoeksenheid; se moatte dit trochgean. It ûnderwerp is echt nij, it sil fierder ûntwikkelje.
Dmitriy:
Ja, tige nijsgjirrich. En dat jildt foar HR. Miskien binne jo HR-proses en HR-merk in bytsje feroare yn dizze 3 jier. Jo begûnen oare minsken te rekrutearjen mei ferskate kompetinsjes. En d'r binne wierskynlik beide foar- en neidielen. Earder wiene blockchain en gegevenswittenskip de hype, en spesjalisten yn har wiene miljoenen wurdich. No falle de kosten, de merk wurdt verzadigd, en d'r is in ferlykbere trend yn mikrotsjinsten.
Sergey:
Jawis.
Alexander:
HR stelt de fraach: "Wêr is jo rôze ienhoarn tusken de efterkant en frontend?" HR begrypt net wat in mikrotsjinst is. Wy fertelden harren it geheim en fertelde harren dat de backend die alles, en der is gjin ienhoarn. Mar HR feroaret, leart fluch en rekrutearret minsken dy't basis IT-kennis hawwe.
De evolúsje fan mikroservices
Dmitriy:
As jo nei de doelarsjitektuer sjogge, sjogge mikrotsjinsten sa'n meunster. Jo reis duorre ferskate jierren. Oaren hawwe in jier, oaren trije jier. Hawwe jo alle problemen foarsjoen, de doelarsjitektuer, feroare der wat? Bygelyks, yn it gefal fan mikrotsjinsten, poarten en tsjinstmeshes ferskine no wer. Hawwe jo se yn it begjin brûkt of hawwe jo de arsjitektuer sels feroare? Hawwe jo sokke útdagings?
Sergey:
Wy hawwe al ferskate kommunikaasjeprotokollen opnij skreaun. Earst wie der ien protokol, no binne wy oerstapt nei in oar. Wy ferheegje feiligens en betrouberens. Wy binne begûn mei ûndernimmingstechnologyen - Oracle, Web Logic. No geane wy fuort fan technologyske ûndernimmingsprodukten yn mikrotsjinsten en ferhúzje nei iepen boarne as folslein iepen technologyen. Wy ferlitte databases en gean nei wat effektiver foar ús wurket yn dit model. Wy hawwe gjin Oracle-technologyen mear nedich.
Wy begûnen gewoan as in tsjinst, sûnder te tinken oer hoefolle wy in cache nedich wiene, wat wy soene dwaan as der gjin ferbining wie mei in mikrotsjinst, mar gegevens nedich wiene, ensfh. No ûntwikkelje wy in platfoarm sadat de arsjitektuer beskreaun wurde kin. net yn 'e taal fan tsjinsten, en yn saaklike taal, nim saaklike logika nei it folgjende nivo as wy begjinne te praten yn wurden. No hawwe wy leard te praten yn letters, en it folgjende nivo is as de tsjinsten wurde sammele yn in soarte fan aggregaat, as dit al in wurd is - bygelyks in hiele produktkaart. It is gearstald út mikrotsjinsten, mar it is in API boud boppe op dit.
Feiligens is tige wichtich. Sadree't jo begjinne tagonklik te wêzen en jo in tsjinst hawwe wêrmei jo in protte nijsgjirrige dingen kinne krije, en heul snel, yn in split sekonde, dan is d'r in winsk om it op in net de feilichste manier te krijen. Om hjir fuort te kommen, moasten wy oanpak feroarje foar testen en tafersjoch. Wy moasten feroarje it team, de levering behear struktuer, CI / CD.
Dit is in evolúsje - lykas by tillefoans, allinich folle flugger: earst wiene d'r tillefoans mei drukknoppen, doe ferskynden smartphones. Se hawwe it produkt op 'e nij skreaun en makke om't de merk in oare ferlet hie. Dit is hoe't wy evoluearje: earste klasse, tsiende klasse, wurk.
Iteratyf wurdt der jierliks wat oanlein út it eachpunt fan technyk, wat oars út it eachpunt fan de efterstân en behoeften. Wy ferbine it iene mei it oare. It team besteget 20% oan technyske skulden en technyske stipe foar it team, 80% oan 'e saaklike entiteit. En wy bewege mei in begryp fan wêrom't wy dogge it, wêrom't wy meitsje dizze technologyske ferbetterings, wat se sille liede ta. Fyn dat leuk.
Dmitriy:
Koel. Wat is yn MegaFon?
Alexander:
De wichtichste útdaging doe't wy kamen ta mikroservices wie net te fallen yn gaos. It arsjitekteburo fan MegaFon kaam fuortendaliks by ús, sels waard in inisjatyfnimmer en bestjoerder - no hawwe wy in heul sterke arsjitektuer. Syn taak wie om te begripen hokker doelmodel wy geane en hokker technologyen moatte wurde pilotearre. Mei arsjitektuer hawwe wy dizze pilots sels útfierd.
De folgjende fraach wie: "Hoe kinne jo dit alles dan brûke?" En noch ien: "Hoe kinne jo transparante ynteraksje tusken mikrotsjinsten soargje?" Servicemesh holp ús de lêste fraach te beantwurdzjen. Wy pilotearren Istio en fûnen de resultaten leuk. No binne wy op it poadium fan útrol yn produktive sônes. Wy hawwe in positive hâlding foar alle útdagings - it feit dat wy moatte hieltyd feroarje de stack, leare wat nijs. Wy binne ynteressearre yn it ûntwikkeljen, net it brûken fan âlde oplossingen.
Dmitriy:
Gouden wurden! Sokke útdagings hâlde it team en it bedriuw op har teannen en meitsje de takomst. GDPR makke haadoffisieren foar gegevensbeskerming, en hjoeddeistige útdagings meitsje haadmikrotsjinsten en arsjitektueramtners. En it wol.
Wy hawwe in protte besprutsen. It wichtichste is dat in goed ûntwerp fan mikrotsjinsten en de arsjitektuer sels jo in protte flaters kinne foarkomme. Fansels is it proses iteratyf en evolúsjonêr, mar it is de takomst.
Mei tank oan alle dielnimmers, tank oan Sergei en Alexander!
Fragen út it publyk
Fraach út it publyk (1):
Sergey, hoe is IT-behear feroare yn jo bedriuw? Ik begryp dat as d'r in grutte steapel is fan ferskate systemen, hoe't it wurdt beheard is in frij dúdlik en logysk proses. Hoe hawwe jo it behear fan 'e IT-komponint opnij opboud nei't in heul grut oantal mikrotsjinsten yn sa'n koarte tiid yntegreare binne?
Sergey:
Ik bin it mei myn kollega iens dat arsjitektuer tige wichtich is as oandriuwer fan feroaring. Wy begûnen mei it hawwen fan in arsjitektoanyske divyzje. Arsjitekten binne tagelyk de eigner fan de ferdieling fan funksjonaliteit en de easken foar hoe't dy yn it lânskip ferskine sil. Sa fungearje se ek as koördinator fan dizze feroarings. As gefolch wiene d'r spesifike feroarings oan in spesifyk leveringsproses doe't wy in CI / CD-platfoarm makke hawwe.
Mar de standert, basisprinsipes fan ûntwikkeling, saaklike analyze, testen en ûntwikkeling binne net annulearre. Wy hawwe krekt tafoege snelheid. Earder duorre de syklus safolle, ynstallaasje op testomjouwings duorre safolle mear. No sjocht it bedriuw it foardiel en seit: "Wêrom kinne wy op oare plakken itselde net dwaan?"
It is as, op in goede manier, in ynjeksje yn 'e foarm fan in faksin dat bliken hat: jo kinne it op dizze manier dwaan, mar jo kinne it oars dwaan. Fansels is der in probleem yn personiel, yn kompetinsjes, yn kennis, yn ferset.
Fraach út it publyk (2):
Kritisy fan microservice-arsjitektuer sizze dat testen en ûntwikkeling lestich binne. Dit is logysk wêr't dingen yngewikkeld wurde. Hokker útdagings stie jo team tsjin en hoe hawwe jo se oerwûn? Fraach foar elkenien.
Alexander:
D'r binne swierrichheden by it ferpleatsen fan mikrotsjinsten nei in platfoarm, mar se kinne wurde oplost.
Wy meitsje bygelyks in produkt dat bestiet út 5-7 mikrotsjinsten. Wy moatte yntegraasjetests leverje oer de heule mikrotsjinstenstapel om it griene ljocht te jaan om nei de mastertûke te gean. Dizze taak wie net nij foar ús: wy dogge dit al lang by BSS, doe't de ferkeaper ús al ferstjoerde oplossingen levere.
En ús probleem is allinich yn it lytse team. Ien QA-yngenieur is nedich foar ien betingst produkt. En sa ferstjoere wy in produkt fan 5-7 mikrotsjinsten, wêrfan 2-3 kinne wurde ûntwikkele troch tredden. Wy hawwe bygelyks in produkt yn 'e ûntwikkeling wêrfan ús ferkeaper fan fakturearringsysteem, Mail.ru Group en MegaFon R&D meidwaan. Wy moatte dit dekke mei testen foardat it nei produksje ferstjoere. De QA-yngenieur hat in moanne en in heal wurke oan dit produkt, en de rest fan it team bliuwt sûnder syn stipe.
Dizze kompleksiteit wurdt allinich feroarsake troch skaalfergrutting. Wy begripe dat mikrotsjinsten net kinne bestean yn in fakuüm; absolute isolemint bestiet net. By it feroarjen fan ien tsjinst besykje wy altyd it API-kontrakt te behâlden. As der wat feroaret ûnder de motorkap, bliuwt de tsjinst foarôf. As de wizigingen fataal binne, fynt in soarte fan arsjitektoanyske transformaasje plak en geane wy nei in folslein oar gegevensmetamodel, dat folslein ynkompatibel is - allinich dan prate wy oer de v2-tsjinst API-spesifikaasje dy't ferskynt. Wy stypje de earste en twadde ferzjes tagelyk, en nei alle konsuminten wikselje nei de twadde ferzje, slute wy gewoan de earste.
Sergey:
Ik wol taheakje. Ik bin it perfoarst iens oer komplikaasjes - se barre. It lânskip wurdt komplekser, en de overheadkosten nimme ta, benammen foar testen. Hoe om te gean mei dit: oerskeakelje nei automatisearre testen. Ja, jo sille ekstra moatte ynvestearje yn it skriuwen fan autotests en ienheidstests. Sadat ûntwikkelders net koenen begean sûnder de test troch te gean, koene se de koade net feroarje. Sadat sels de drukknop net wurket sûnder autotest, unit test.
It is wichtich om te behâlden de foarige funksjonaliteit, en dit is ekstra overhead. As jo in technology oerskriuwe nei in oar protokol, dan skriuwe jo it oer oant jo alles folslein slute.
Wy dogge soms net mei opsetsin ein-to-end testen, om't wy de ûntwikkeling net stopje wolle, hoewol wy ek it iene nei it oare hawwe. It lânskip is hiel grut, kompleks, der binne in protte systemen. Soms binne it gewoan stubs - ja, jo ferleegje de feiligensmarge, mear risiko's ferskine. Mar tagelyk jo loslitte it oanbod.
Alexander:
Ja, autotests en ienheidstests kinne jo in tsjinst fan hege kwaliteit meitsje. Wy binne foar in pipeline dy't net kin wurde trochjûn sûnder ienheid- en yntegraasjetests. Wy moatte faak emulators en kommersjele systemen slepe yn test sônes en ûntwikkeling omjouwings, omdat net alle systemen kinne wurde pleatst yn test sônes. Boppedat wurde se net gewoan wiet - wy generearje in folweardich antwurd fan it systeem. Dit is in serieus diel fan it wurkjen mei mikrotsjinsten, en wy ynvestearje der ek yn. Sûnder dit sil gaos ûntstean.
Fraach út it publyk (3):
Foar safier't ik begryp, groeiden mikrotsjinsten ynearsten út in apart team en besteane no yn dit model. Wat binne syn foar- en neidielen?
Wy hawwe gewoan in ferlykber ferhaal: in soarte fan mikroservicefabryk ûntstie. No binne wy konseptueel op it punt kommen dat wy dizze oanpak útwreidzje foar produksje troch streamen en troch systemen. Mei oare wurden, wy geane fuort fan 'e sintralisearre ûntwikkeling fan mikrotsjinsten, mikrotsjinstmodellen, en wurde tichter by systemen.
Dêrtroch giet ús operaasje ek nei systemen, dat is, wy desintralisearje dit ûnderwerp. Wat is jo oanpak en wat is jo doelferhaal?
Alexander:
Jo hawwe de namme "microservices factory" direkt út jo mûle fallen - wy wolle ek skaalfergrutting. Earst hawwe wy no echt ien team. Wy wolle alle ûntwikkelingsteams dy't MegaFon hat de kâns jaan om te wurkjen yn in mienskiplik ekosysteem. Wy wolle alle ûntwikkelingsfunksjonaliteit dy't wy no hawwe net folslein oernimme. De lokale taak is skaalfergrutting, de globale taak is om ûntwikkeling te lieden nei alle teams yn 'e mikroservicelaach.
Sergey:
Ik sil jo it paad fertelle dat wy hawwe makke. Wy binne echt begongen as ien team te wurkjen, mar no binne wy net allinich. Ik bin in foarstanner fan it folgjende: der moat in eigener wêze fan it proses. Immen moat it ûntwikkelingsproses fan mikrotsjinsten begripe, beheare, kontrolearje en bouwe. Hy moat eigen boarnen hawwe en him dwaande hâlde mei boarnebehear.
Dizze boarnen, dy't technologyen, spesifikaasjes kenne en begripe hoe't jo mikrotsjinsten kinne bouwe, kinne lizze yn produktteams. Wy hawwe in miks wêr't minsken fan it mikroserviceplatfoarm binne yn it produktteam dat de mobile applikaasje makket. Se binne der, mar se wurkje neffens it proses fan 'e ôfdieling microservice platfoarm behear mei harren ûntwikkeling manager. Binnen dizze ôfdieling is der in apart team dat him dwaande hâldt mei technology. Dat is, wy mingje in mienskiplike pool fan boarnen ûnder ússels en ferdiele se, jouwe se oan teams.
Tagelyk bliuwt it proses algemien, kontrolearre, it giet neffens algemiene technologyske prinsipes, mei ienheidstesten en sa op - alles dat boppe-op boud is. D'r kinne kolommen wêze yn 'e foarm fan boarnen sammele fan ferskate ôfdielingen fan' e produktoanpak.
Alexander:
Sergey, jo binne eins de eigner fan it proses, krekt? Is de taakefterstân dield? Wa is ferantwurdlik foar de distribúsje?
Sergey:
Sjoch: hjir is de miks wer. D'r is in efterstân dy't wurdt foarme op basis fan technologyske ferbetteringen - dit is ien ferhaal. Der is in efterstân, dy't formulearre wurdt út projekten, en der is in efterstân fan produkten. Mar de folchoarder fan yntroduksje yn elk fan 'e tsjinstprodukten as it meitsjen fan dizze tsjinst wurdt ûntwikkele troch in produktspesjalist. Hy sit net yn de IT-direktoraat, hy is dêr spesjaal fuorthelle. Mar myn minsken wurkje perfoarst neffens itselde proses.
De eigner fan 'e efterstân yn ferskate rjochtingen - de efterstân fan feroaringen - sil ferskate minsken wêze. De ferbining fan technologyske tsjinsten, harren organisearjende prinsipe - dit alles sil wêze yn IT. Ik besit it platfoarm en de boarnen ek. Oan 'e boppekant is wat de efterstân en funksjonele feroarings oanbelanget, en de arsjitektuer yn dizze sin.
Litte wy sizze dat in bedriuw seit: "Wy wolle dizze funksje, wy wolle in nij produkt meitsje - in liening opnij meitsje." Wy antwurdzje: "Ja, wy sille it opnij dwaan." Arsjitekten sizze: "Litte wy tinke: wêr yn 'e liening sille wy mikrotsjinsten skriuwe en hoe sille wy it dwaan?" Dan brekke wy it op yn projekten, produkten of in technologystapel, sette it yn teams en implementearje it. Hawwe jo yntern in produkt makke en besletten mikrotsjinsten yn dit produkt te brûken? Wy sizze: "No moatte de legacy-systemen dy't wy hiene, as frontline-systemen, oerskeakelje nei dizze mikrotsjinsten." De arsjitekten sizze: "Dus: yn 'e technologyske efterstân yn' e frontlineprodukten - de oergong nei mikrotsjinsten. Gean". En produktspesjalisten as bedriuwseigners begripe hoefolle kapasiteit wurdt tawiisd, wannear't it sil dien wurde en wêrom.
De ein fan 'e diskusje, mar net alles
De mailto:CLOUD-konferinsje waard organisearre .
Wy dogge ek oare eveneminten - bgl. @Kubernetes Meetup, wêr't wy altyd op syk binne nei geweldige sprekkers:
- Folgje @Kubernetes en oar @Meetup-nijs yn ús Telegram-kanaal
- Ynteressearre om te praten by ien fan 'e @Meetups? Lit in fersyk foar
Boarne: www.habr.com