25. aprila smo u Mail.ru Group održali konferenciju o oblacima i oko - . Nekoliko naglasaka:
- Glavni — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center i Yandex.Cloud govorili su o specifičnostima našeg tržišta oblaka i svojih usluga;
- Kolege iz Bitrix24 ispričale su kako su ;
- Zanimljivo su dali Leroy Merlin, Otkritie, Burger King i Schneider Electric — koje zadatke njihovo poslovanje postavlja za IT i koje tehnologije, uključujući i one u oblaku, vide kao najperspektivnije.
Možete pogledati sve video zapise sa mailto:CLOUD konferencije , a ovdje možete pročitati kako je tekla rasprava o mikroservisima. Aleksandar Deulin, šef centra za istraživanje i razvoj poslovnih sistema MegaFon, i Sergej Sergejev, direktor informacionih tehnologija grupe M.Video-Eldorado, podijelili su svoje uspješne slučajeve rješavanja monolita. Također smo razgovarali o pitanjima IT strategije, procesa, pa čak i ljudskih resursa.
Panelisti
- Sergey Sergeev, Grupa CIO "M.Video-Eldorado";
- Alexander Deulin, rukovodilac Centra za istraživanje i razvoj poslovnih sistema MegaFon;
- Moderator — Dmitry Lazarenko, šef PaaS smjera Mail.ru Cloud rješenja.
Nakon govora Aleksandra Deulina u diskusiji mu se pridružuju Sergej Sergejev iz M.Video-Eldorado i moderator diskusije Dmitrij Lazarenko, Mail.ru Cloud Solutions.
U nastavku smo za vas pripremili transkript diskusije, ali možete pogledati i video:
Prelazak na mikrousluge je odgovor na potrebe tržišta
Dmitrij:
Da li ste imali uspješno iskustvo migriranja na mikrousluge? I općenito: gdje vidite najveću poslovnu korist od korištenja mikroservisa ili prelaska s monolita na mikroservise?
Sergej:
Već smo prešli neki put u tranziciji na mikrousluge i koristimo ovaj pristup više od tri godine. Prva potreba koja je opravdala potrebu za mikrouslugama bila je beskonačna integracija različitih front-end proizvoda sa back office-om. I svaki put smo bili primorani na dodatnu integraciju i razvoj, implementirajući vlastita pravila za rad ove ili one usluge.
U nekom trenutku smo shvatili da moramo ubrzati rad naših sistema i izlaz funkcionalnosti. U tom trenutku na tržištu su već postojali koncepti kao što su mikroservis i mikroservisni pristup, a mi smo odlučili da to isprobamo. Ovo je počelo 2016. Zatim je postavljena platforma i prvih 10 servisa je implementiran od strane posebnog tima.
Jedna od prvih usluga, najopterećenija, bila je usluga obračuna cijena. Svaki put kada dođete na bilo koji kanal, u grupu kompanija M.Video-Eldorado, bilo da se radi o web stranici ili maloprodaji, tamo odaberete proizvod, vidite cijenu na web stranici ili u „Kopi“, trošak se automatski obračunava jedan servis. Zašto je to potrebno: prije toga, svaki sistem je imao svoje principe za rad s promocijama - s popustima i tako dalje. Naš back office upravlja cijenama, a funkcionalnost popusta implementirana je u drugom sistemu. Ovo je trebalo centralizirati i stvoriti jedinstvenu, odvojivu uslugu u obliku poslovnog procesa koji bi nam omogućio da to implementiramo. Tako smo otprilike počeli.
Vrijednost prvih rezultata bila je vrlo velika. Prvo, bili smo u mogućnosti da kreiramo odvojive entitete koji nam omogućavaju da radimo odvojeno i na agregirani način. Drugo, smanjili smo troškove vlasništva u smislu integracije sa više sistema.
U protekle tri godine dodali smo tri frontline sistema. Bilo ih je teško održavati sa istom količinom resursa koju je kompanija mogla priuštiti. Stoga se nametnuo zadatak da se traže nova prodajna mesta, koja odgovaraju tržištu u smislu brzine, internih troškova i efikasnosti.
Kako izmjeriti uspjeh migracije na mikrousluge
Dmitrij:
Kako se određuje uspjeh u migraciji na mikroservise? Šta je bilo “prije” u svakoj kompaniji? Koju metriku ste koristili da odredite uspjeh tranzicije i ko ga je zapravo odredio?
Sergej:
Prije svega, rođen je unutar IT-a kao pokretač – „otključavanje“ novih mogućnosti. Imali smo potrebu da sve radimo brže za relativno isti novac, odgovarajući na izazove tržišta. Sada se uspjeh izražava u broju usluga koje ponovo koriste različiti sistemi, objedinjavanju procesa među sobom. Sada jeste, ali u tom trenutku je bila prilika da napravimo platformu i potvrdimo hipotezu da to možemo, to će dati efekat i izračunati poslovni slučaj.
Aleksandar:
Uspeh je pre unutrašnje osećanje. Posao uvijek želi više, a dubina našeg zaostatka je dokaz uspjeha. Tako mi se čini.
Sergej:
Da, slažem se. Za tri godine već imamo više od dvije stotine usluga i zaostataka. Potreba za resursima unutar tima samo raste - za 30% godišnje. To se dešava jer su ljudi osjetili: brže je, drugačije je, postoje različite tehnologije, sve se to razvija.
Mikroservis će doći, ali jezgro će ostati
Dmitrij:
To je kao beskrajni proces u kojem ulažete u razvoj. Da li je prelazak na mikroservise za poslovanje već završen ili nije?
Sergej:
Vrlo je lako odgovoriti. Šta mislite: zamjena telefona je beskrajan proces? Mi sami kupujemo telefone svake godine. I evo ga: sve dok postoji potreba za brzinom, za prilagođavanjem tržištu, bit će potrebne neke promjene. To ne znači da napuštamo standardne stvari.
Ali ne možemo pokriti i ponoviti sve odjednom. Imamo naslijeđene, standardne usluge integracije koje su postojale prije: poslovne sabirnice i tako dalje. Ali postoji zaostatak, a postoji i potreba. Broj mobilnih aplikacija i njihova funkcionalnost raste. Istovremeno, niko ne kaže da ćete dobiti 30% više novca. Odnosno, s jedne strane uvijek postoje potrebe, a s druge potraga za efikasnošću.
Dmitrij:
Život je u dobrom stanju. (smijeh)
Aleksandar:
Generalno, da. Nemamo revolucionarne pristupe uklanjanju jezgra iz pejzaža. U toku je sistematski rad na dekomponovanju sistema kako bi bili u skladu sa mikroservisnom arhitekturom, kako bi se smanjio uticaj sistema jedni na druge.
Ali planiramo zadržati osnovni dio, jer će u okruženju operatera uvijek postojati neke platforme koje kupujemo. Opet, potrebna nam je zdrava ravnoteža: ne bismo trebali žuriti s isjecanjem jezgra. Sisteme postavljamo jedan pored drugog, a sada se ispostavilo da smo već na vrhu mnogih ključnih delova. Dalje, razvijajući funkcionalnost, kreiramo potrebne reprezentacije za sve kanale koji rade sa našim komunikacijskim uslugama.
Kako prodati mikrousluge preduzećima
Dmitrij:
I mene zanima - za one koji nisu prešli, ali planiraju: koliko je bilo lako prodati ovu ideju biznisu i da li je to bila avantura, investicioni projekat? Ili je to bila svjesna strategija: sada idemo na mikroservise i to je to, ništa nas neće zaustaviti. Kako ti je bilo?
Sergej:
Nismo prodavali pristup, već poslovnu korist. Postojao je problem u poslovanju i mi smo ga pokušali riješiti. U tom trenutku se to izražavalo u činjenici da su različiti kanali koristili različite principe za obračun cijena - posebno za promocije, za promocije i tako dalje. Bilo je teško održavati, dešavale su se greške i slušali smo pritužbe kupaca. Odnosno, prodavali smo rješenje problema, ali smo došli sa činjenicom da nam je potreban novac za kreiranje platforme. I prikazali su poslovni slučaj na primjeru prve faze investicije: kako ćemo je nastaviti nadoknađivati i šta će nam to omogućiti.
Dmitrij:
Jeste li nekako zabilježili vrijeme prve etape?
Sergej:
Da naravno. Odvojili smo 6 mjeseci da kreiramo jezgro kao platformu i testiramo pilot. Za to vreme smo pokušali da napravimo platformu na kojoj će klizati pilot. Tada je hipoteza potvrđena, a pošto funkcionira, znači da možemo nastaviti. Počeli su replicirati i ojačati tim - premjestili su ga u posebnu diviziju koja radi upravo to.
Slijedi sistematski rad baziran na poslovnim potrebama, mogućnostima, dostupnosti resursa i svemu što se trenutno radi.
Dmitrij:
UREDU. Aleksandre, šta kažeš?
Aleksandar:
Naši mikroservis su rođeni iz “pjene mora” - zbog uštede resursa, zbog nekih zaostatka u vidu kapaciteta servera i preraspodjele snaga unutar tima. U početku ovaj projekat nismo prodali biznisu. Ovo je bio projekat u kojem smo oboje istraživali i razvijali se u skladu s tim. Počeli smo početkom 2018. i jednostavno smo sa entuzijazmom razvijali ovaj pravac. Prodaja je tek počela i mi smo u procesu.
Dmitrij:
Da li se dešava da vam preduzeće dozvoljava da radite takve stvari kao što je Google - na jedan slobodan dan u sedmici? Imate li takav pravac?
Aleksandar:
Uporedo sa istraživanjem bavili smo se i poslovnim problemima, tako da su sve naše mikroservise rješenja za poslovne probleme. Samo na početku smo izgradili mikroservise koji su pokrivali mali dio pretplatničke baze, a sada smo prisutni u gotovo svim flagship proizvodima.
A materijalni uticaj je već jasan – već se možemo prebrojati, brzina lansiranja proizvoda i izgubljeni prihod može se procijeniti da smo išli starim putem. Ovo je ono na čemu gradimo slučaj.
Mikrousluge: hype ili neophodnost?
Dmitrij:
Brojevi su brojevi. A prihod ili ušteđeni novac je veoma važan. Šta ako pogledate s druge strane? Čini se da su mikroservise trend, hype i mnoge kompanije to zloupotrebljavaju? Koliko jasno pravite razliku između onoga što radite i onoga što ne prevodite na mikrousluge? Ako je naslijeđe sada, hoćete li i dalje imati naslijeđe za 5 godina? Koliko će biti stari informacioni sistemi koji rade u M.Video-Eldoradu i MegaFonu za 5 godina? Hoće li postojati desetogodišnji, petnaestogodišnji informacioni sistemi ili će to biti nova generacija? Kako vidite ovo?
Sergej:
Čini mi se da je teško razmišljati veoma daleko. Ako pogledamo unazad, ko je zamislio da će se tehnološko tržište razvijati na ovaj način, uključujući mašinsko učenje i identifikaciju korisnika licem? Ali ako pogledate naredne godine, čini mi se da osnovni sistemi, sistemi ERP klase preduzeća u kompanijama – funkcionišu već dosta dugo.
Naše kompanije su zajedno stare 25 godina, sa klasičnim ERP-om veoma duboko u sistemskom pejzažu. Jasno je da neke dijelove vadimo odatle i pokušavamo ih agregirati u mikroservise, ali jezgro će ostati. Sada mi je teško zamisliti da ćemo tamo zamijeniti sve osnovne sisteme i brzo preći na drugu, svijetlu stranu novih sistema.
Pobornik sam činjenice da je sve što je bliže klijentu i potrošaču tamo gdje je najveća poslovna korist i vrijednost, gdje su prilagodljivost i fokus na brzinu, na promjenu, na „probaj, otkaži, ponovo iskoristi, uradi nešto drugačije“ potrebno “—tamo će se pejzaž promijeniti. A proizvodi u kutijama se tu ne uklapaju baš najbolje. Barem to ne vidimo. Tu su potrebna najlakša i najjednostavnija rješenja.
Vidimo ovaj razvoj:
- osnovni informacioni sistemi (uglavnom back office);
- srednji slojevi u obliku mikroservisa povezuju jezgro, agregiraju, kreiraju keš memoriju i tako dalje;
- front-line sistemi su usmereni na potrošača;
- integracioni sloj koji je generalno integrisan u tržišta, druge sisteme i ekosisteme. Ovaj sloj je što je moguće lakši, jednostavan i sadrži minimum poslovne logike.
Ali u isto vrijeme, ja sam pristalica nastavka korištenja starih principa ako se koriste na odgovarajući način.
Recimo da imate klasičan sistem preduzeća. Nalazi se u pejzažu jednog dobavljača i sastoji se od dva modula koji rade jedan s drugim. Postoji i standardni interfejs za integraciju. Zašto to ponoviti i dovesti mikroservis tamo?
Ali kada se u back office-u nalazi 5 modula iz kojih se informacije prikupljaju u poslovni proces, koje potom koristi 8-10 front-line sistema, korist je odmah uočljiva. Uzimate iz pet back-office sistema i kreirate uslugu, izolovanu, koja je fokusirana na poslovni proces. Učinite uslugu tehnološki naprednom - tako da kešira informacije i bude otporna na greške, a radi i sa dokumentima ili poslovnim subjektima. I integrišete ga prema jednom principu sa svim front-line proizvodima. Otkazali su prvi proizvod - jednostavno su isključili integraciju. Sutra treba da napišete mobilnu aplikaciju ili napravite malu web stranicu i samo jedan dio stavite u funkcionalnost - sve je jednostavno: sastavili ste ga kao konstruktor. Vidim više razvoja u tom pravcu - barem kod nas.
Aleksandar:
Sergej je u potpunosti opisao naš pristup, hvala. Reći ću samo gdje definitivno nećemo ići - na suštinu, na temu online naplate. Odnosno, rejting i naplata će ostati, u stvari, „velika“ vršalica koja će pouzdano otpisivati novac. I ovaj sistem će i dalje biti certificiran od strane naših regulatornih tijela. Sve ostalo što je okrenuto klijentima, naravno, su mikroservise.
Dmitrij:
Ovdje je certifikacija jedna priča. Vjerovatno više podrške. Ako trošite malo na podršku ili sistem ne zahtijeva podršku i modifikacije, bolje je ne dirati ga. Razuman kompromis.
Kako razviti pouzdane mikroservise
Dmitrij:
U redu. Ali i dalje sam zainteresovan. Sada pričate priču o uspjehu: sve je bilo u redu, prešli smo na mikroservise, odbranili ideju biznisu i sve je uspjelo. Ali čuo sam i druge priče.
Prije nekoliko godina, švicarska kompanija koja je uložila dvije godine u razvoj nove mikroservisne platforme za banke na kraju je zatvorila projekat. Potpuno srušen. Potrošeno je mnogo miliona švajcarskih franaka, a na kraju je tim raspršen - nije išlo.
Jeste li imali slične priče? Da li je bilo ili ima poteškoća? Na primjer, održavanje mikroservisa i nadzor je također glavobolja u operativnim aktivnostima kompanije. Na kraju krajeva, broj komponenti se povećava desetinama puta. Kako vidite, da li je ovdje bilo neuspješnih primjera ulaganja? I šta možete savjetovati ljudima da ne naiđu na takve probleme?
Aleksandar:
Neuspješni primjeri su uključivali kompanije koje su promijenile prioritete i otkazale projekte. Kada je u dobroj fazi spremnosti (u stvari, MVP je spreman), biznis je rekao: "Imamo nove prioritete, prelazimo na drugi projekat, a ovaj zatvaramo."
Nismo imali nikakvih globalnih propusta sa mikroservisima. Spavamo mirno, imamo dežurstvo 24/7 koje servisira cijeli BSS [sistem poslovne podrške].
I još nešto - mikroservise iznajmljujemo po pravilima koja važe za pakirane proizvode. Ključ uspjeha je u tome što morate prije svega okupiti tim koji će u potpunosti pripremiti mikroservis za proizvodnju. Sam razvoj je, uslovno, 40%. Ostalo je analitika, DevSecOps metodologija, prave integracije i prava arhitektura. Posebnu pažnju posvećujemo principima izgradnje sigurnih aplikacija. Predstavnici informacione sigurnosti učestvuju u svakom projektu kako u fazi planiranja arhitekture tako i tokom procesa implementacije. Oni takođe upravljaju sistemima za analizu koda za ranjivosti.
Recimo da implementiramo naše usluge bez državljanstva - imamo ih u Kubernetesu. Ovo omogućava svima da mirno spavaju zbog automatskog skaliranja i automatskog podizanja usluga, a dežurna smjena otkriva incidente.
U cijelom postojanju naših mikroservisa, dogodila su se samo jedan ili dva incidenta koji su dospjeli na našu liniju. Sada nema problema sa radom. Mi, naravno, nemamo 200, već oko 50 mikroservisa, ali oni se koriste u vodećim proizvodima. Ako nisu uspjeli, mi bismo prvi saznali za to.
Mikrousluge i HR
Sergej:
Slažem se sa kolegom oko prelaska na podršku - da se rad treba pravilno organizovati. Ali reći ću vam o problemima koji, naravno, postoje.
Prvo, tehnologija je nova. Ovo je hype na dobar način, a pronaći stručnjaka koji će to razumjeti i može stvoriti je veliki izazov. Konkurencija za resurse je luda, pa su stručnjaci zlata vrijedni.
Drugo, stvaranjem određenih pejzaža i sve većim brojem usluga, problem ponovne upotrebe mora se stalno rješavati. Kao što programeri vole da rade: „Hajde da sada ovde napišemo mnogo zanimljivih stvari...“ Zbog toga sistem raste i gubi svoju efikasnost u smislu novca, troškova vlasništva itd. Odnosno, potrebno je uključiti ponovnu upotrebu u arhitekturu sistema, uključiti je u mapu puta za uvođenje servisa i prenošenje naslijeđa na novu arhitekturu.
Drugi problem - iako je to dobro na svoj način - je interna konkurencija. “Oh, ovdje su se pojavili novi moderni momci, govore novi jezik.” Ljudi su, naravno, različiti. Ima onih koji su navikli pisati u Javi, i onih koji pišu i koriste Docker i Kubernetes. To su potpuno različiti ljudi, različito govore, koriste različite izraze i ponekad se ne razumiju. Sposobnost ili nemogućnost dijeljenja prakse, razmjene znanja, u tom smislu je također problem.
Pa, skaliranje resursa. “Odlično, idemo! A sada želimo brže, više. Šta, ne možeš? Zar nije moguće isporučiti duplo više za godinu dana? I zašto?" Takvi bolovi rasta su vjerovatno standardni za mnoge stvari, mnoge pristupe i možete ih osjetiti.
Što se tiče monitoringa. Čini mi se da usluge ili alati za industrijsko praćenje već uče ili su u stanju da rade i sa Dockerom i Kubernetesom u drugačijem, nestandardnom načinu rada. Tako da, na primjer, ne završite sa 500 Java mašina pod kojima sve ovo radi, odnosno agregira. Ali ovim proizvodima još uvijek nedostaje zrelosti, oni moraju proći kroz to. Tema je zaista nova, razvijaće se dalje.
Dmitrij:
Da, vrlo zanimljivo. I ovo se odnosi na HR. Možda su se vaš HR proces i HR brend malo promijenili u ove 3 godine. Počeli ste da regrutujete druge ljude sa različitim kompetencijama. I vjerovatno ima i za i protiv. Ranije su blockchain i nauka o podacima bili popularni, a stručnjaci za njih vrijedili su milione. Sada cijena pada, tržište postaje zasićeno, a sličan trend postoji i u mikrouslugama.
Sergej:
Da, apsolutno.
Aleksandar:
HR postavlja pitanje: "Gdje je vaš ružičasti jednorog između backenda i frontenda?" HR ne razumije šta je mikroservis. Rekli smo im tajnu i rekli im da je bekend uradio sve, a jednorog ne postoji. Ali HR se mijenja, brzo uči i zapošljava ljude koji imaju osnovno IT znanje.
Evolucija mikroservisa
Dmitrij:
Ako pogledate ciljnu arhitekturu, mikroservis izgleda kao takvo čudovište. Vaše putovanje je trajalo nekoliko godina. Drugi imaju godinu dana, drugi tri godine. Jeste li predvidjeli sve probleme, ciljnu arhitekturu, da li se nešto promijenilo? Na primjer, u slučaju mikroservisa, pristupnici i servisne mreže se sada ponovo pojavljuju. Jeste li ih koristili na početku ili ste promijenili samu arhitekturu? Imate li takvih izazova?
Sergej:
Već smo prepisali nekoliko komunikacijskih protokola. U početku je postojao jedan protokol, sada smo prešli na drugi. Povećavamo sigurnost i pouzdanost. Počeli smo sa poslovnim tehnologijama - Oracle, Web Logic. Sada se udaljavamo od tehnoloških poslovnih proizvoda u mikrouslugama i prelazimo na open source ili potpuno otvorene tehnologije. Napuštamo baze podataka i prelazimo na ono što nam je efikasnije u ovom modelu. Više nam ne trebaju Oracle tehnologije.
Počeli smo jednostavno kao servis, ne razmišljajući o tome koliko nam je potreban keš, šta bismo radili kada nije bilo veze sa mikroservisom, ali su bili potrebni podaci itd. Sada razvijamo platformu da se arhitektura može opisati ne jezikom usluga, već poslovnim jezikom, podignite poslovnu logiku na viši nivo kada počnemo da pričamo rečima. Sada smo naučili da govorimo slovima, a sledeći nivo je kada će usluge biti sakupljene u neku vrstu agregata, kada je to već reč - na primer, cela kartica proizvoda. Sastavljen je od mikroservisa, ali je API izgrađen na vrhu ovoga.
Sigurnost je veoma važna. Čim počnete da budete pristupačni i imate servis preko kojeg možete dobiti mnogo zanimljivih stvari, i to vrlo brzo, u djeliću sekunde, onda se javlja želja da to dobijete na ne baš najsigurniji način. Da bismo pobjegli od ovoga, morali smo promijeniti pristup testiranju i praćenju. Morali smo promijeniti tim, strukturu upravljanja isporukom, CI/CD.
Ovo je evolucija – kao i kod telefona, samo mnogo brže: prvo su postojali telefoni na dugme, a zatim su se pojavili pametni telefoni. Prepisali su i redizajnirali proizvod jer je tržište imalo drugačiju potrebu. Ovako se razvijamo: prvi razred, deseti razred, posao.
Iterativno, nešto se godišnje izlaže sa stanovišta tehnologije, nešto drugo sa stanovišta zaostatka i potreba. Povezujemo jednu stvar sa drugom. Tim troši 20% na tehnički dug i tehničku podršku timu, 80% na poslovni subjekt. I krećemo se sa razumijevanjem zašto to radimo, zašto pravimo ta tehnološka poboljšanja, do čega će ona dovesti. Kao to.
Dmitrij:
Cool. Šta je u MegaFonu?
Aleksandar:
Glavni izazov kada smo došli do mikroservisa bio je da ne zapadnemo u haos. Arhitektonski biro MegaFona odmah nam se pridružio, čak postao inicijator i pokretač - sada imamo veoma jaku arhitekturu. Njegov zadatak je bio da shvati na koji ciljni model idemo i koje tehnologije treba pilotirati. Sa arhitekturom smo sami izveli ove pilote.
Sljedeće pitanje je bilo: “Kako onda sve ovo iskoristiti?” I još jedno: "Kako osigurati transparentnu interakciju između mikroservisa?" Servisna mreža nam je pomogla da odgovorimo na posljednje pitanje. Probali smo Istio i svidjeli su nam se rezultati. Sada smo u fazi uvođenja u produktivne zone. Imamo pozitivan stav prema svim izazovima – činjenici da moramo stalno mijenjati stack, naučiti nešto novo. Zainteresovani smo za razvoj, a ne za iskorištavanje starih rješenja.
Dmitrij:
Zlatne riječi! Takvi izazovi drže tim i poslovanje na nogama i stvaraju budućnost. GDPR je stvorio glavne službenike za zaštitu podataka, a trenutni izazovi stvaraju glavne službenike za mikroservise i arhitekturu. I prija.
Mnogo smo razgovarali. Glavna stvar je da dobar dizajn mikroservisa i sama arhitektura omogućavaju izbjegavanje mnogih grešaka. Naravno, proces je iterativan i evolucijski, ali to je budućnost.
Hvala svim učesnicima, hvala Sergeju i Aleksandru!
Pitanja iz publike
Pitanje iz publike (1):
Sergej, kako se promijenio IT menadžment u vašoj kompaniji? Razumijem da kada postoji veliki snop od nekoliko sistema, način na koji se njime upravlja je prilično jasan i logičan proces. Kako ste ponovo izgradili upravljanje IT komponentom nakon što je veoma veliki broj mikroservisa integrisan u tako kratko vreme?
Sergej:
Slažem se sa kolegom da je arhitektura veoma važna kao pokretač promena. Počeli smo tako što smo imali arhitektonski odjel. Arhitekte su istovremeno i vlasnici distribucije funkcionalnosti i zahtjeva kako će ona izgledati u krajoliku. Dakle, oni također djeluju kao koordinatori ovih promjena. Kao rezultat toga, došlo je do specifičnih promjena u specifičnom procesu isporuke kada smo kreirali CI/CD platformu.
Ali standard, osnovni principi razvoja, poslovne analize, testiranja i razvoja nisu otkazani. Samo smo dodali brzinu. Ranije je ciklus trajao toliko, instalacija na testnim okruženjima je zahtijevala mnogo više. Sada biznis vidi korist i kaže: „Zašto to ne bismo mogli učiniti i na drugim mjestima?“
To je kao, na dobar način, injekcija u obliku vakcine koja je pokazala: možete to učiniti na ovaj način, ali možete to učiniti na drugi način. Naravno, postoji problem u kadrovima, u kompetencijama, u znanju, u otporu.
Pitanje iz publike (2):
Kritičari mikroservisne arhitekture kažu da su testiranje i razvoj teški. Ovo je logično kada se stvari zakomplikuju. S kojim se izazovima suočio vaš tim i kako ste ih savladali? Pitanje za sve.
Aleksandar:
Postoje poteškoće pri prelasku sa mikroservisa na platformu, ali one se mogu riješiti.
Na primjer, pravimo proizvod koji se sastoji od 5-7 mikroservisa. Moramo obezbijediti integracijske testove u cijelom steku mikroservisa kako bismo dali zeleno svjetlo za prelazak na glavnu granu. Ovaj zadatak za nas nije bio nov: to smo radili dugo vremena u BSS-u, kada nam je dobavljač isporučio već isporučena rješenja.
A naš problem je samo u malom timu. Za jedan uslovni proizvod potreban je jedan QA inženjer. I tako, isporučujemo proizvod od 5-7 mikroservisa, od kojih 2-3 mogu razviti treće strane. Na primjer, imamo proizvod u čijem razvoju učestvuje naš dobavljač sistema naplate, Mail.ru Group i MegaFon R&D. Moramo to pokriti testovima prije nego što ga pošaljemo u proizvodnju. QA inženjer radi na ovom proizvodu mjesec i po dana, a ostatak tima je ostao bez njegove podrške.
Ova složenost je uzrokovana samo skaliranjem. Razumijemo da mikrousluge ne mogu postojati u vakuumu; apsolutna izolacija ne postoji. Prilikom promjene jednog servisa uvijek se trudimo da sačuvamo API ugovor. Ako se nešto promijeni ispod haube, ostaje prednji servis. Ako su promjene fatalne, dolazi do neke vrste arhitektonske transformacije i prelazimo na potpuno drugačiji metamodel podataka, koji je potpuno nekompatibilan - tek tada govorimo o pojavi v2 servis API specifikacije. Podržavamo prvu i drugu verziju istovremeno, a nakon što svi potrošači pređu na drugu verziju, jednostavno zatvaramo prvu.
Sergej:
Želim da dodam. Apsolutno se slažem sa komplikacijama - one se dešavaju. Krajolik postaje složeniji, a režijski troškovi se povećavaju, posebno za testiranje. Kako se nositi s ovim: pređite na automatsko testiranje. Da, morat ćete dodatno uložiti u pisanje autotestova i jediničnih testova. Tako da programeri nisu mogli da urezuju bez prolaska testa, nisu mogli promijeniti kod. Tako da čak ni dugme ne radi bez autotest, jedinični test.
Važno je zadržati prethodnu funkcionalnost, a to je dodatni trošak. Ako prepišete tehnologiju na drugi protokol, onda je prepisujete dok ne zatvorite sve u potpunosti.
Ponekad ne radimo end-to-end testiranje namjerno, jer ne želimo zaustaviti razvoj, iako imamo i jednu stvar za drugom. Pejzaž je veoma velik, složen, ima mnogo sistema. Ponekad su to samo zaglavci - da, smanjite sigurnosnu marginu, pojavljuje se više rizika. Ali u isto vrijeme oslobađate zalihe.
Aleksandar:
Da, autotestovi i jedinični testovi omogućavaju vam da kreirate uslugu visokog kvaliteta. Mi smo za cevovod koji se ne može proći bez jediničnih i integracijskih testova. Često moramo da prevlačimo emulatore i komercijalne sisteme u testne zone i razvojna okruženja, jer se ne mogu svi sistemi postaviti u testne zone. Štaviše, oni se ne pokvase samo - mi generišemo potpuni odgovor sistema. Ovo je ozbiljan dio rada sa mikroservisima i u to ulažemo. Bez toga će nastati haos.
Pitanje iz publike (3):
Koliko sam shvatio, mikroservis je u početku izrastao iz zasebnog tima i sada postoji u ovom modelu. Koje su njegove prednosti i mane?
Imamo samo sličnu priču: nastala je neka vrsta fabrike mikroservisa. Sada smo konceptualno došli do toga da ovaj pristup proširujemo na proizvodnju po tokovima i sistemima. Drugim riječima, udaljavamo se od centraliziranog razvoja mikroservisa, mikroservisnih modela, i postajemo bliži sistemima.
Shodno tome, naše poslovanje ide i na sisteme, odnosno decentraliziramo ovu temu. Kakav je vaš pristup i koja je vaša ciljna priča?
Aleksandar:
Izbacili ste naziv "fabrika mikroservisa" pravo iz usta - mi također želimo povećati. Prvo, sada zaista imamo jedan tim. Želimo svim razvojnim timovima koje MegaFon ima omogućiti da rade u zajedničkom ekosistemu. Ne želimo u potpunosti preuzeti svu razvojnu funkcionalnost koju sada imamo. Lokalni zadatak je skaliranje, globalni zadatak je voditi razvoj do svih timova u mikroservisnom sloju.
Sergej:
Reći ću vam put kojim smo išli. Zaista smo počeli da radimo kao jedan tim, ali sada nismo sami. Ja sam zagovornik sljedećeg: mora postojati vlasnik procesa. Neko treba da razume, upravlja, kontroliše i izgradi proces razvoja mikroservisa. On mora posjedovati resurse i uključiti se u upravljanje resursima.
Ovi resursi, koji poznaju tehnologije, specifičnosti i razumiju kako izgraditi mikroservise, mogu se nalaziti u timovima proizvoda. Imamo miks u kojem su ljudi sa mikroservisne platforme u proizvodnom timu koji pravi mobilnu aplikaciju. Oni su tu, ali rade prema procesu odeljenja za upravljanje mikroservisnom platformom sa svojim menadžerom razvoja. U okviru ove divizije postoji poseban tim koji se bavi tehnologijom. To jest, mi miješamo zajednički fond resursa između sebe i dijelimo ih, dajući ih timovima.
Istovremeno, proces ostaje opći, kontroliran, odvija se po općim tehnološkim principima, uz unit testing i tako dalje – sve što se nadograđuje. Mogu postojati kolone u obliku resursa prikupljenih iz različitih odjela pristupa proizvoda.
Aleksandar:
Sergej, ti si zapravo vlasnik procesa, zar ne? Da li se zaostatak zadataka dijeli? Ko je odgovoran za njegovu distribuciju?
Sergej:
Vidite: evo opet mješavine. Postoji zaostatak koji se formira na osnovu tehnoloških poboljšanja – to je jedna priča. Postoji zaostatak koji je formuliran iz projekata, a postoji i zaostatak od proizvoda. Ali redoslijed uvođenja u svaki od uslužnih proizvoda ili kreiranja ove usluge razvija stručnjak za proizvode. On nije u IT direkciji, iz nje je posebno smijenjen. Ali moji ljudi definitivno rade po istom procesu.
Vlasnik zaostatka u različitim smjerovima - zaostatak promjena - bit će različiti ljudi. Povezivanje tehnoloških usluga, njihov princip organizacije - sve će to biti u IT-u. Posjedujem i platformu i resurse. Na vrhu je ono što se tiče zaostalih i funkcionalnih promjena, te arhitekture u tom smislu.
Recimo da preduzeće kaže: "Želimo ovu funkciju, želimo da kreiramo novi proizvod - prepravimo kredit." Odgovaramo: "Da, ponovićemo." Arhitekte kažu: "Hajde da razmislimo: gde ćemo u kreditu napisati mikroservise i kako ćemo to uraditi?" Zatim ga rastavljamo na projekte, proizvode ili tehnološku grupu, stavljamo u timove i implementiramo. Da li ste interno kreirali proizvod i odlučili da koristite mikroservise u ovom proizvodu? Kažemo: „Sada naslijeđeni sistemi koje smo imali, ili sistemi na prvoj liniji, moraju se prebaciti na ove mikrousluge.“ Arhitekti kažu: „Dakle: u tehnološkom zaostatku unutar proizvoda na prvoj liniji - prelazak na mikrousluge. Idi". A stručnjaci za proizvode ili vlasnici preduzeća razumiju koliki je kapacitet dodijeljen, kada će to biti urađeno i zašto.
Kraj rasprave, ali ne sve
Organizirana je mailto:CLOUD konferencija .
Radimo i druge događaje - npr. @Kubernetes Meetup, gdje uvijek tražimo odlične zvučnike:
- Pratite @Kubernetes i druge @Meetup vijesti na našem Telegram kanalu
- Zainteresovani ste za govor na nekom od @Meetupova? Ostavite zahtjev za
izvor: www.habr.com