25. travnja mi u Mail.ru Group održali smo konferenciju o oblacima i oko njih - . Nekoliko naglasaka:
- Glavni — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center i Yandex.Cloud govorili su o specifičnostima našeg cloud tržišta i njihovim uslugama;
- Kolege iz Bitrix24 rekli su kako su ;
- Zanimljivo su pružili Leroy Merlin, Otkritie, Burger King i Schneider Electric — koje zadatke njihovo poslovanje postavlja pred IT i koje tehnologije, uključujući one u oblaku, vide kao najperspektivnije.
Možete pogledati sve videe s konferencije mailto:CLOUD , a ovdje možete pročitati kako je tekla rasprava o mikroservisima. Alexander Deulin, voditelj MegaFon centra za istraživanje i razvoj poslovnih sustava, i Sergey Sergeev, direktor informacijske tehnologije grupe M.Video-Eldorado, podijelili su svoje uspješne slučajeve rješavanja monolita. Također smo razgovarali o povezanim pitanjima IT strategije, procesa, pa čak i ljudskih resursa.
Panelisti
- Sergej Sergejev, CIO grupe "M.Video-Eldorado";
- Aleksandar Deulin, voditeljica centra za istraživanje i razvoj poslovnih sustava MegaFon;
- Moderator — Dmitrij Lazarenko, voditelj smjera PaaS Mail.ru Cloud rješenja.
Nakon govora Aleksandra Deulina u raspravi mu se pridružuju Sergey Sergeev iz M.Video-Eldorado i moderator rasprave Dmitry Lazarenko, Mail.ru Cloud Solutions.
U nastavku smo za vas pripremili transkript rasprave, ali možete pogledati i video:
Prelazak na mikrousluge odgovor je na potrebe tržišta
Dmitrij:
Jeste li imali kakvo uspješno iskustvo migracije na mikroservise? I općenito: gdje vidite najveću poslovnu korist od korištenja mikroservisa ili prelaska s monolita na mikroservise?
Sergej:
Već smo ponešto odmakli u tranziciji na mikroservise i ovaj pristup koristimo više od tri godine. Prva potreba koja je opravdala potrebu za mikroservisima bila je beskrajna integracija raznih front-end proizvoda sa back officeom. I svaki put smo bili prisiljeni napraviti dodatnu integraciju i razvoj, implementirajući vlastita pravila za rad ove ili one usluge.
U jednom smo trenutku shvatili da moramo ubrzati rad naših sustava i izlaz funkcionalnosti. U tom trenutku na tržištu su već postojali koncepti poput mikroservisa i mikroservisnog pristupa, te smo odlučili isprobati. Ovo je počelo 2016. Zatim je postavljena platforma i prvih 10 usluga implementirano je od strane zasebnog tima.
Jedna od prvih usluga, najopterećenija, bila je usluga izračuna cijena. Svaki put kada dođete na bilo koji kanal, u grupu tvrtki M.Video-Eldorado, bilo da se radi o web stranici ili maloprodajnoj trgovini, tamo odaberete proizvod, vidite cijenu na web stranici ili u "Košarici", trošak se automatski obračunava jedna služba. Zašto je to potrebno: prije toga, svaki sustav je imao svoje principe rada s promocijama - s popustima i tako dalje. Naš back office bavi se cijenama, a funkcija popusta implementirana je u drugom sustavu. Ovo je trebalo centralizirati i stvoriti jedinstvenu, odvojivu uslugu u obliku poslovnog procesa koji bi nam omogućio da to implementiramo. Otprilike tako smo počeli.
Vrijednost prvih rezultata bila je vrlo velika. Prvo, uspjeli smo stvoriti odvojive entitete koji nam omogućuju da radimo odvojeno i združeno. Drugo, smanjili smo troškove vlasništva u smislu integracije s više sustava.
Tijekom protekle tri godine dodali smo tri frontline sustava. Bilo ih je teško održavati s istom količinom resursa koje je tvrtka mogla priuštiti. Stoga se pojavio zadatak traženja novih prodajnih mjesta koja će odgovoriti tržištu u smislu brzine, u smislu internih troškova i učinkovitosti.
Kako izmjeriti uspjeh migracije na mikroservise
Dmitrij:
Kako se određuje uspjeh u prelasku na mikroservise? Što je bilo "prije" u svakoj tvrtki? Kojom metrikom ste odredili uspješnost tranzicije i tko ju je zapravo odredio?
Sergej:
Prije svega, rođen je unutar IT-a kao pokretač - "otključavanje" novih mogućnosti. Imali smo potrebu sve napraviti brže za relativno isti novac, odgovarajući na izazove tržišta. Sada se uspjeh izražava u broju usluga koje različiti sustavi ponovno koriste, međusobnom objedinjavanju procesa. Sada jest, ali u tom trenutku to je bila prilika da stvorimo platformu i potvrdimo hipotezu da to možemo učiniti, to će dati učinak i izračunati poslovni slučaj.
Aleksandar:
Uspjeh je više unutarnji osjećaj. Posao uvijek želi više, a dubina našeg zaostatka dokaz je uspjeha. Tako mi se čini.
Sergej:
Da, slažem se. U tri godine imamo već više od dvjesto usluga i zaostataka. Potreba za resursima unutar tima samo raste – za 30% godišnje. To se događa jer su ljudi osjetili: brže je, drugačije je, postoje različite tehnologije, sve se to razvija.
Mikroservisi će doći, ali jezgra će ostati
Dmitrij:
To je kao neprestani proces u kojem ulažete u razvoj. Je li prijelaz na mikroservise za poslovanje već gotov ili nije?
Sergej:
Vrlo je lako odgovoriti. Što mislite: zamjena telefona je beskrajan proces? Mi sami kupujemo telefone svake godine. I evo ga: sve dok postoji potreba za brzinom, za prilagodbom tržištu, bit će potrebne neke promjene. To ne znači da odustajemo od standardnih stvari.
Ali ne možemo pokriti i ponoviti sve odjednom. Imamo naslijeđene, standardne usluge integracije koje su bile dostupne prije: poslovne sabirnice i tako dalje. Ali ima zaostataka, a postoji i potreba. Broj mobilnih aplikacija i njihova funkcionalnost raste. Pritom nitko ne kaže da će vam se dati 30% više novca. Odnosno, s jedne strane uvijek postoje potrebe, a s druge strane traženje učinkovitosti.
Dmitrij:
Život je u dobroj formi. (Smijeh)
Aleksandar:
Općenito, da. Mi nemamo revolucionarne pristupe uklanjanju središnjeg dijela krajolika. U tijeku je sustavni rad na dekompoziciji sustava kako bi bili dosljedniji arhitekturi mikroservisa, kako bi se smanjio utjecaj sustava jednih na druge.
Ali planiramo zadržati osnovni dio, budući da će u krajoliku operatera uvijek postojati neke platforme koje kupujemo. Opet, trebamo zdravu ravnotežu: ne bismo trebali žuriti s izrezivanjem jezgre. Postavljamo sustave jedan pored drugog, a sada se ispostavlja da smo već na vrhu mnogih ključnih dijelova. Nadalje, razvijajući funkcionalnost, stvaramo potrebne reprezentacije za sve kanale koji rade s našim komunikacijskim uslugama.
Kako prodati mikrousluge poduzećima
Dmitrij:
Također me zanima - za one koji nisu prešli, ali planiraju: koliko je bilo lako ovu ideju prodati biznisu i je li to bila avantura, investicijski projekt? Ili je to bila svjesna strategija: sad idemo na mikroservise i to je to, ništa nas neće zaustaviti. Kako je vama bilo?
Sergej:
Nismo prodavali pristup, nego poslovnu korist. Pojavio se problem u poslovanju i pokušali smo ga riješiti. U tom trenutku to se izrazilo u činjenici da su različiti kanali koristili različite principe za izračun cijena - zasebno za promocije, za promocije i tako dalje. Bilo ga je teško održavati, događale su se greške, slušali smo pritužbe kupaca. Odnosno, prodavali smo rješenje problema, ali smo došli s činjenicom da nam treba novac za stvaranje platforme. I prikazali su poslovni slučaj na primjeru prve faze investicije: kako ćemo je dalje vraćati i što će nam to omogućiti.
Dmitrij:
Jeste li nekako zabilježili vrijeme prve etape?
Sergej:
Da naravno. Dodijelili smo 6 mjeseci za izradu jezgre kao platforme i testiranje pilota. Tijekom tog vremena pokušali smo stvoriti platformu na kojoj bi mogao skejtati pilot. Tada je hipoteza potvrđena, a budući da funkcionira, znači da možemo nastaviti. Počeli su replicirati i ojačati tim – prebacili su ga u zasebnu diviziju koja radi upravo to.
Slijedi sustavan rad temeljen na poslovnim potrebama, mogućnostima, raspoloživosti resursa i svemu onom što se trenutno radi.
Dmitrij:
U REDU. Alexander, što kažeš?
Aleksandar:
Naši mikroservisi su rođeni iz “pjene od mora” - zbog uštede resursa, zbog nekih ostataka u vidu serverskih kapaciteta i preraspodjele snaga unutar tima. U početku ovaj projekt nismo prodali poduzećima. Ovo je bio projekt u kojem smo i istraživali i razvijali se u skladu s tim. Krenuli smo početkom 2018. i jednostavno s entuzijazmom razvijali ovaj smjer. Prodaja je tek počela, a mi smo u procesu.
Dmitrij:
Događa li se da vam tvrtka omogući da radite takve stvari poput Googlea - jedan slobodan dan u tjednu? Imate li takav smjer?
Aleksandar:
Paralelno s istraživanjem bavili smo se i poslovnim problemima, tako da su svi naši mikroservisi rješenja za poslovne probleme. Samo na početku smo izgradili mikroservise koji su pokrivali mali dio baze pretplatnika, a sada smo prisutni u gotovo svim flagship proizvodima.
A materijalni učinak je već jasan - već nas se može prebrojati, brzina lansiranja proizvoda i gubitak prihoda može se procijeniti da smo išli starim putem. To je ono na čemu gradimo slučaj.
Mikroservisi: hype ili nužnost?
Dmitrij:
Brojevi su brojevi. A prihod ili ušteđeni novac vrlo su važni. Što ako pogledate s druge strane? Čini se da su mikroservisi trend, hype i mnoge tvrtke to zlorabe? Koliko jasno razlikujete ono što radite i ono što ne prevodite na mikroservise? Ako naslijeđe sada, hoćete li i dalje imati nasljeđe za 5 godina? Kolika će biti starost informacijskih sustava koji rade u M.Video-Eldoradu i MegaFonu za 5 godina? Hoće li biti informacijskih sustava starih deset, petnaest godina ili će to biti nova generacija? Kako ti vidiš ovo?
Sergej:
Čini mi se da je teško misliti jako daleko. Ako pogledamo unatrag, tko je zamislio da će se tehnološko tržište razvijati na ovaj način, uključujući strojno učenje i identifikaciju korisnika licem? Ali ako pogledate godine koje dolaze, čini mi se da temeljni sustavi, sustavi poslovne ERP klase u tvrtkama - rade već dosta dugo.
Naše tvrtke zajedno su stare 25 godina, s klasičnim ERP-om vrlo duboko u sustavima. Jasno je da vadimo neke dijelove odatle i pokušavamo ih agregirati u mikroservise, ali jezgra će ostati. Sada mi je teško zamisliti da ćemo tamo zamijeniti sve temeljne sustave i brzo prijeći na drugu, svijetlu stranu novih sustava.
Pobornik sam toga da je sve što je bliže klijentu i potrošaču najveća poslovna korist i vrijednost, gdje je prilagodljivost i usmjerenost na brzinu, na promjenu, na “probaj, odustani, ponovno upotrijebi, napravi nešto drugačije” potreban “—tu će se krajolik promijeniti. A proizvodi u kutiji tamo se ne uklapaju baš najbolje. Barem mi to ne vidimo. Tu su potrebna najlakša, najjednostavnija rješenja.
Vidimo ovaj razvoj:
- temeljni informacijski sustavi (uglavnom back office);
- srednji slojevi u obliku mikroservisa povezuju jezgru, agregiraju, stvaraju predmemoriju i tako dalje;
- front-line sustavi su usmjereni na potrošača;
- integracijski sloj koji je općenito integriran u tržišta, druge sustave i ekosustave. Ovaj sloj je što lakši, jednostavan i sadrži minimum poslovne logike.
Ali u isto vrijeme, ja sam pobornik nastavka korištenja starih principa ako se koriste na odgovarajući način.
Recimo da imate klasični poslovni sustav. Nalazi se u krajoliku jednog dobavljača i sastoji se od dva modula koji rade jedan s drugim. Tu je i standardno integracijsko sučelje. Zašto to ponoviti i tamo unijeti mikroservis?
Ali kada u back officeu postoji 5 modula iz kojih se informacije skupljaju u poslovni proces koji zatim koristi 8-10 front-line sustava, korist je odmah vidljiva. Uzimate iz pet back-office sustava i kreirate uslugu, izoliranu, koja je fokusirana na poslovni proces. Učinite uslugu tehnološki naprednom - tako da sprema informacije i da je tolerantna na greške, a također radi s dokumentima ili poslovnim subjektima. I integrirate ga prema jednom principu sa svim prvim proizvodima. Otkazali su front-line proizvod – jednostavno su isključili integraciju. Sutra trebate napisati mobilnu aplikaciju ili napraviti malu web stranicu i samo jedan dio staviti u funkciju - sve je jednostavno: složili ste to kao konstruktor. Vidim još razvoja u tom smjeru – barem kod nas.
Aleksandar:
Sergej je u potpunosti opisao naš pristup, hvala. Samo ću reći gdje definitivno nećemo ići - na srž, na temu online naplate. Odnosno, ocjena i naplata će ostati, zapravo, "velika" vršalica koja će pouzdano otpisati novac. I ovaj će sustav nastaviti certificirati naša regulatorna tijela. Sve ostalo što gleda prema klijentima su naravno mikroservisi.
Dmitrij:
Ovdje je certifikacija jedna priča. Vjerojatno više podrške. Ako trošite malo na podršku ili sustav ne zahtijeva podršku i izmjene, bolje je ne dirati ga. Razuman kompromis.
Kako razviti pouzdane mikroservise
Dmitrij:
Fino. Ali svejedno me zanima. Sada pričate priču o uspjehu: sve je bilo u redu, prešli smo na mikroservise, obranili ideju u poslovanju i sve je uspjelo. Ali čuo sam i druge priče.
Prije nekoliko godina jedna švicarska tvrtka koja je dvije godine ulagala u razvoj nove mikroservisne platforme za banke na kraju je zatvorila projekt. Potpuno propao. Potrošeno je mnogo milijuna švicarskih franaka, a na kraju je momčad raspršena - nije uspjelo.
Jeste li imali slične priče? Je li bilo ili ima poteškoća? Na primjer, održavanje mikroservisa i nadzor također predstavlja glavobolju u operativnim aktivnostima tvrtke. Uostalom, broj komponenti povećava se desetke puta. Kako na to gledate, je li ovdje bilo neuspješnih primjera ulaganja? I što možete savjetovati ljudima da se ne susreću s takvim problemima?
Aleksandar:
Neuspješni primjeri uključivali su tvrtke koje su mijenjale prioritete i otkazivale projekte. Kada je u dobroj fazi spremnosti (zapravo, MVP je spreman), tvrtka je rekla: "Imamo nove prioritete, prelazimo na drugi projekt, a ovaj zatvaramo."
Nismo imali nikakvih globalnih kvarova s mikroservisima. Spavamo mirno, imamo dežurstvo 24/7 koje servisira cijeli BSS [sustav poslovne podrške].
I još nešto - mikroservise iznajmljujemo prema pravilima koja vrijede za boxed proizvode. Ključ uspjeha je da prvo morate okupiti tim koji će u potpunosti pripremiti mikroservis za proizvodnju. Sama razvijenost je, uvjetno, 40%. Ostalo je analitika, DevSecOps metodologija, prave integracije i prava arhitektura. Posebnu pozornost posvećujemo načelima izgradnje sigurnih aplikacija. Predstavnici informacijske sigurnosti sudjeluju u svakom projektu kako u fazi planiranja arhitekture tako i tijekom procesa implementacije. Oni također upravljaju sustavima za analizu koda za ranjivosti.
Recimo da implementiramo naše usluge bez državljanstva – imamo ih u Kubernetesu. To omogućuje da svi mirno spavaju zbog auto-skalanja i autodizanja servisa, a dežurstva preuzimaju incidente.
U cijelom postojanju naših mikroservisa, dogodila su se samo jedan ili dva incidenta koji su stigli do naše linije. Sada nema problema s radom. Mi, naravno, nemamo 200, već oko 50 mikroservisa, ali oni se koriste u vodećim proizvodima. Da nisu uspjeli, mi bismo prvi saznali za to.
Mikroservisi i HR
Sergej:
Slažem se s kolegom oko premještaja na podršku - da posao treba pravilno organizirati. 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ći stvoriti veliki je izazov. Natjecanje za resurse je ludo, pa su stručnjaci zlata vrijedni.
Drugo, stvaranjem određenih krajolika i sve većim brojem usluga, problem ponovne upotrebe mora se stalno rješavati. Kao što programeri vole raditi: "Napišimo ovdje sada mnogo zanimljivih stvari..." Zbog toga sustav raste i gubi svoju učinkovitost u smislu novca, troškova vlasništva i tako dalje. Odnosno, potrebno je uključiti ponovnu upotrebu u arhitekturu sustava, uključiti je u mapu puta za uvođenje usluga i prijenos nasljeđa na novu arhitekturu.
Još jedan problem - iako je to na svoj način dobro - je unutarnja konkurencija. "Oh, ovdje su se pojavili novi moderni tipovi, govore novim jezikom." 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, dijeljenja znanja, u tom smislu je također problem.
Pa, skaliranje resursa. “Odlično, idemo! A sada želimo brže, više. Što, ne možeš? Zar nije moguće isporučiti duplo više u godinu dana? I zašto?" Takvi bolovi rasta vjerojatno su standardni za mnoge stvari, mnoge pristupe i možete ih osjetiti.
Što se tiče praćenja. Čini mi se da usluge ili industrijski alati za nadzor već uče ili mogu raditi i s Dockerom i s Kubernetesom u drugačijem, nestandardnom načinu rada. Da, primjerice, ne dobijete 500 Java strojeva pod kojima sve to radi, naime, agregira. Ali tim proizvodima još uvijek nedostaje zrelost; moraju to proći. Tema je stvarno nova, dalje će se razvijati.
Dmitrij:
Da, vrlo zanimljivo. I ovo se odnosi na HR. Možda su se vaš HR proces i HR brand malo promijenili u ove 3 godine. Počeli ste zapošljavati druge ljude s različitim kompetencijama. A vjerojatno postoje i prednosti i mane. Ranije su blockchain i podatkovna znanost bili popularni, a stručnjaci za njih vrijedili su milijune. Sada cijena pada, tržište postaje zasićeno, a sličan je trend i kod mikroservisa.
Sergej:
Da apsolutno.
Aleksandar:
HR postavlja pitanje: "Gdje je vaš ružičasti jednorog između pozadine i sučelja?" HR ne razumije što je mikroservis. Otkrili smo im tajnu i rekli im da je backend učinio sve i da nema jednoroga. Ali HR se mijenja, brzo uči i zapošljava ljude koji imaju osnovno IT znanje.
Evolucija mikroservisa
Dmitrij:
Ako pogledate ciljnu arhitekturu, mikroservisi izgledaju kao takvo čudovište. Vaše putovanje trajalo je nekoliko godina. Drugi imaju godinu, treći tri godine. Jeste li predvidjeli sve probleme, ciljnu arhitekturu, je li se što promijenilo? Na primjer, u slučaju mikrousluga, pristupnici i servisne mreže sada se ponovno pojavljuju. Jeste li ih koristili u početku ili ste promijenili samu arhitekturu? Imate li takvih izazova?
Sergej:
Već smo ponovno napisali nekoliko komunikacijskih protokola. Prvo je bio jedan protokol, sad smo prešli na drugi. Povećavamo sigurnost i pouzdanost. Počeli smo s enterprise tehnologijama - Oracle, Web Logic. Sada se odmičemo od tehnoloških enterprise proizvoda u mikroservisima i prelazimo na open source ili potpuno otvorene tehnologije. Napuštamo baze podataka i prelazimo na ono što nam u ovom modelu učinkovitije funkcionira. Više nam ne trebaju Oracle tehnologije.
Počeli smo jednostavno kao servis, bez razmišljanja o tome koliko nam treba cache, što ćemo raditi kada nema veze s mikroservisom, a potrebni su podaci itd. Sada razvijamo platformu kako bi se mogla opisati arhitektura ne jezikom usluga, nego poslovnim jezikom, dignite poslovnu logiku na višu razinu kada počnemo govoriti riječima. Sada smo naučili govoriti slovima, a sljedeća je razina kada će se usluge skupiti u neku vrstu agregata, kada je to već riječ - na primjer, cijela kartica proizvoda. Sastavljen je od mikroservisa, ali je API izgrađen na ovome.
Sigurnost je vrlo važna. Čim počnete biti pristupačni i imate uslugu preko koje možete dobiti puno zanimljivih stvari, i to vrlo brzo, u djeliću sekunde, tada se javlja želja da to dobijete na ne baš najsigurniji način. Kako 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 puno brža: prvo su bili telefoni s tipkama, a zatim su se pojavili pametni telefoni. Prepisali su i redizajnirali proizvod jer je tržište imalo drugačije potrebe. Ovako se razvijamo: prvi razred, deseti razred, rad.
Iterativno, godišnje se nešto postavlja s gledišta tehnologije, nešto drugo s gledišta zaostatka i potreba. Povezujemo jednu stvar s drugom. Tim troši 20% na tehnički dug i tehničku podršku za tim, 80% na poslovni subjekt. I krećemo s razumijevanjem zašto to radimo, zašto radimo ta tehnološka poboljšanja, čemu će ona dovesti. ovako.
Dmitrij:
Cool. Što je u Megafonu?
Aleksandar:
Glavni izazov kada smo došli do mikroservisa bio je ne upasti u kaos. Arhitektonski ured MegaFona odmah nam se pridružio, čak postao inicijator i pokretač - sada imamo vrlo jaku arhitekturu. Njegov je zadatak bio shvatiti prema kojem ciljnom modelu idemo i koje tehnologije treba pilotirati. Što se tiče arhitekture, sami smo proveli te pilote.
Sljedeće pitanje je bilo: "Kako onda sve to iskoristiti?" I još jedno: “Kako osigurati transparentnu interakciju između mikroservisa?” Service mesh pomogao nam je odgovoriti na zadnje pitanje. Isprobali smo Istio i svidjeli su nam se rezultati. Sada smo u fazi izvođenja u proizvodne zone. Imamo pozitivan stav prema svim izazovima – činjenici da treba stalno mijenjati stack, učiti nešto novo. Zainteresirani smo za razvoj, a ne za iskorištavanje starih rješenja.
Dmitrij:
Zlatne riječi! Takvi izazovi drže tim i posao 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 godi.
Puno smo raspravljali. Glavna stvar je da dobar dizajn mikroservisa i same arhitekture omogućuje izbjegavanje mnogih pogrešaka. Naravno, proces je iterativan i evolucijski, ali to je budućnost.
Hvala svim sudionicima, hvala Sergeju i Aleksandru!
Pitanja iz publike
Pitanje iz publike (1):
Sergej, kako se promijenio IT menadžment u vašoj tvrtki? Razumijem da kada postoji veliki hrp od nekoliko sustava, kako se njime upravlja prilično je jasan i logičan proces. Kako ste ponovno izgradili upravljanje IT komponentom nakon što je u tako kratkom vremenu integriran jako velik broj mikroservisa?
Sergej:
Slažem se s kolegom da je arhitektura vrlo važna kao pokretač promjena. Počeli smo s arhitektonskim odjelom. Arhitekti su istovremeno vlasnici distribucije funkcionalnosti i zahtjeva kako će se ona pojaviti u krajoliku. Dakle, oni također djeluju kao koordinatori tih promjena. Kao rezultat toga, došlo je do specifičnih promjena u određenom procesu isporuke kada smo stvorili CI/CD platformu.
Ali standard, temeljna načela razvoja, poslovne analize, testiranja i razvoja nisu otkazani. Samo smo dodali brzinu. Prethodno je ciklus trajao toliko, instalacija na testnim okruženjima trajala je mnogo više. Sada tvrtka vidi korist i kaže: "Zašto se to ne može učiniti na drugim mjestima?"
To je kao, na dobar način, injekcija u obliku cjepiva koja je pokazala: možeš ovako, ali možeš i drugačije. Naravno, problem je 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. To je logično tamo gdje se stvari kompliciraju. S kakvim se izazovima vaš tim susreo i kako ste ih prevladali? Pitanje za sve.
Aleksandar:
Postoje poteškoće pri prelasku s mikroservisa na platformu, ali one se mogu riješiti.
Na primjer, radimo proizvod koji se sastoji od 5-7 mikroservisa. Moramo osigurati integracijske testove na cijelom nizu mikroservisa kako bismo dali zeleno svjetlo za prelazak na glavnu granu. Ovaj zadatak za nas nije bio nov: u BSS-u smo to radili dugo vremena, kada nam je dobavljač isporučio već isporučena rješenja.
A naš problem je samo u malom timu. Za jedan uvjetni 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 sudjeluju naš dobavljač sustava za naplatu, Mail.ru Group i MegaFon R&D. To moramo pokriti testovima prije slanja u proizvodnju. QA inženjer je na ovom proizvodu radio mjesec i pol, a ostatak tima ostao je bez njegove podrške.
Ovu složenost uzrokuje samo skaliranje. Shvaćamo da mikroservisi ne mogu postojati u vakuumu; apsolutna izolacija ne postoji. Prilikom promjene jedne usluge uvijek nastojimo sačuvati API ugovor. Ako se nešto promijeni ispod haube, prednji servis ostaje. Ako su promjene fatalne, dolazi do neke vrste arhitektonske transformacije i prelazi se na potpuno drugačiji podatkovni metamodel, koji je potpuno nekompatibilan – tek tada govorimo o pojavi v2 service API specifikacije. Prvu i drugu verziju podržavamo istovremeno, a nakon što svi korisnici prijeđu na drugu verziju, prvu jednostavno zatvaramo.
Sergej:
želim dodati. Za komplikacije se apsolutno slažem - događaju se. Krajolik postaje sve složeniji, a opći troškovi rastu, posebno za testiranje. Kako se nositi s tim: prebacite se na automatizirano testiranje. Da, morat ćete dodatno uložiti u pisanje autotestova i jediničnih testova. Kako se programeri ne bi mogli obvezati bez prolaska testa, nisu mogli promijeniti kod. Tako da ni tipkalo ne radi bez autotesta, unit testa.
Bitno je zadržati prijašnju funkcionalnost, a to su dodatni troškovi. Ako prepišete tehnologiju na drugi protokol, tada je prepisujete dok sve potpuno ne zatvorite.
Ponekad namjerno ne radimo end-to-end testiranje, jer ne želimo zaustaviti razvoj, iako također imamo jednu stvar za drugom. Krajolik je jako velik, složen, ima mnogo sustava. Ponekad su to samo nedostaci - da, smanjite sigurnosnu granicu, pojavljuje se više rizika. Ali u isto vrijeme oslobađate opskrbu.
Aleksandar:
Da, autotestovi i jedinični testovi omogućuju vam stvaranje usluge visoke kvalitete. Mi smo za cjevovod koji se ne može proći bez jediničnih i integracijskih testova. Često moramo vući emulatore i komercijalne sustave u testne zone i razvojna okruženja, jer se svi sustavi ne mogu smjestiti u testne zone. Štoviše, ne samo da se smoče - mi generiramo potpuni odgovor sustava. Ovo je ozbiljan dio rada s mikroservisima iu to također ulažemo. Bez toga će nastati kaos.
Pitanje iz publike (3):
Koliko ja razumijem, mikroservisi su u početku izrasli iz zasebnog tima i sada postoje u ovom modelu. Koje su njegove prednosti i mane?
Imamo samo sličnu priču: nastala je nekakva tvornica mikroservisa. Sada smo konceptualno došli do toga da ovaj pristup proširujemo na proizvodnju po tokovima i po sustavima. Drugim riječima, udaljavamo se od centraliziranog razvoja mikroservisa, mikroservisnih modela i približavamo se sustavima.
Sukladno tome, naše djelovanje ide i na sustave, odnosno tu temu decentraliziramo. Kakav je vaš pristup i koja je vaša ciljna priča?
Aleksandar:
Izbacili ste naziv "tvornica mikrousluga" ravno iz usta - mi također želimo skalirati. Prvo, sada stvarno imamo jedan tim. Svim razvojnim timovima koje MegaFon ima želimo pružiti priliku da rade u zajedničkom ekosustavu. Ne želimo u potpunosti preuzeti sve razvojne funkcije koje sada imamo. Lokalni zadatak je skaliranje, globalni zadatak je voditi razvoj za sve timove u sloju mikroservisa.
Sergej:
Reći ću vam put kojim smo krenuli. Zaista smo počeli raditi kao jedan tim, ali sada nismo sami. Ja sam zagovornik sljedećeg: mora postojati vlasnik procesa. Netko mora razumjeti, upravljati, kontrolirati i graditi proces razvoja mikroservisa. Mora posjedovati resurse i uključiti se u upravljanje resursima.
Ovi resursi, koji poznaju tehnologije, specifičnosti i razumiju kako izgraditi mikroservise, mogu se smjestiti u timove proizvoda. Imamo mješavinu u kojoj su ljudi iz platforme mikroservisa u proizvodnom timu koji izrađuje mobilnu aplikaciju. Oni su tu, ali rade po procesu odjela za upravljanje mikroservisnom platformom sa svojim voditeljem razvoja. Unutar ove divizije postoji poseban tim koji se bavi tehnologijom. To jest, međusobno miješamo zajednički skup resursa i dijelimo ih dajući timovima.
Istovremeno, proces ostaje općeniti, kontroliran, odvija se prema općim tehnološkim principima, s jediničnim testiranjem i tako dalje - sve što se nadograđuje. Mogu postojati stupci u obliku izvora prikupljenih iz različitih odjela pristupa proizvodu.
Aleksandar:
Sergej, ti si zapravo vlasnik procesa, zar ne? Dijele li se zaostali zadaci? Tko je odgovoran za njegovu distribuciju?
Sergej:
Pogledajte: evo opet mješavine. Postoji zaostatak koji nastaje na temelju tehnoloških poboljšanja – to je jedna priča. Postoji zaostatak, koji je formuliran iz projekata, i postoji zaostatak iz proizvoda. Ali redoslijed uvođenja u svaki uslužni proizvod ili stvaranje ove usluge razvija stručnjak za proizvode. On nije u Upravi za informatiku, iz nje je posebno maknut. Ali moji ljudi definitivno rade prema istom procesu.
Vlasnik zaostatka u različitim smjerovima – zaostatka promjena – bit će drugi ljudi. Povezivanje tehnoloških usluga, njihov organizacijski princip - sve će to biti u IT-u. Vlasnik sam platforme i resursa. Na vrhu je ono što se tiče zaostalih i funkcionalnih promjena, te arhitekture u tom smislu.
Recimo da tvrtka kaže: "Želimo ovu funkciju, želimo stvoriti novi proizvod - prepraviti zajam." Odgovaramo: "Da, ponovit ćemo." Arhitekti kažu: "Razmislimo: gdje ćemo u kreditu napisati mikroservise i kako ćemo to učiniti?" Zatim ga rastavljamo na projekte, proizvode ili tehnološki skup, stavljamo u timove i implementiramo. Jeste li interno izradili proizvod i odlučili koristiti mikrousluge u ovom proizvodu? Kažemo: "Sada naslijeđeni sustavi koje smo imali, ili prvi sustavi, moraju se prebaciti na ove mikroservise." Arhitekti kažu: “Dakle: u tehnološkom zaostatku unutar prvih proizvoda - prijelaz na mikroservise. Ići". A stručnjaci za proizvode ili vlasnici tvrtki razumiju koliko je kapaciteta dodijeljeno, kada će to biti učinjeno i zašto.
Kraj rasprave, ali ne sve
Organizirana je konferencija mailto:CLOUD .
Radimo i druge događaje - npr. @Kubernetes susret, gdje smo uvijek u potrazi za izvrsnim govornicima:
- Pratite @Kubernetes i ostale @Meetup vijesti na našem Telegram kanalu
- Zainteresirani ste za govor na jednom od @Meetups? Ostavite zahtjev za
Izvor: www.habr.com