25. april holdt vi i Mail.ru Group en konferanse om skyer og rundt - . Noen få høydepunkter:
- Hoved — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center og Yandex.Cloud snakket om spesifikasjonene til skymarkedet vårt og deres tjenester;
- Kolleger fra Bitrix24 fortalte hvordan de ;
- Leroy Merlin, Otkritie, Burger King og Schneider Electric sørget for interessant — hvilke oppgaver virksomheten deres setter for IT og hvilke teknologier, inkludert skyen, ser de på som de mest lovende.
Du kan se alle videoer fra mailto:CLOUD-konferansen , og her kan du lese hvordan diskusjonen om mikrotjenester gikk. Alexander Deulin, leder av MegaFon forretningssystemers forsknings- og utviklingssenter, og Sergey Sergeev, informasjonsteknologidirektør i M.Video-Eldorado-gruppen, delte sine vellykkede tilfeller av å bli kvitt monolitter. Vi diskuterte også relaterte spørsmål om IT-strategi, prosesser og til og med HR.
Paneldeltakere
- Sergey Sergeev, konsernsjef "M.Video-Eldorado";
- Alexander Deulin, leder for senter for forskning og utvikling av forretningssystemer MegaFon;
- Moderator - Dmitry Lazarenko, Leder for PaaS-retning Mail.ru skyløsninger.
Etter talen til Alexander Deulin han får selskap for diskusjon av Sergey Sergeev fra M.Video-Eldorado og diskusjonsmoderator Dmitry Lazarenko, Mail.ru Cloud Solutions.
Nedenfor har vi utarbeidet en utskrift av diskusjonen for deg, men du kan også se videoen:
Overgangen til mikrotjenester er et svar på markedets behov
Dmitriy:
Har du hatt noen vellykket erfaring med å migrere til mikrotjenester? Og generelt: hvor ser du størst forretningsgevinst ved å bruke mikrotjenester eller gå fra monolitter til mikrotjenester?
Sergey:
Vi har allerede kommet et stykke i overgangen til mikrotjenester og har brukt denne tilnærmingen i mer enn tre år. Det første behovet som rettferdiggjorde behovet for mikrotjenester var den endeløse integrasjonen av ulike front-end-produkter med backoffice. Og hver gang ble vi tvunget til å gjøre ytterligere integrasjon og utvikling, implementere våre egne regler for driften av denne eller den tjenesten.
På et tidspunkt innså vi at vi trengte å fremskynde driften av systemene våre og produksjonen av funksjonalitet. I det øyeblikket eksisterte konsepter som mikrotjenester og en mikrotjenestetilnærming allerede på markedet, og vi bestemte oss for å prøve det. Dette startet i 2016. Deretter ble plattformen lagt og de første 10 tjenestene ble implementert av et eget team.
En av de første tjenestene, den mest belastede, var prisberegningstjenesten. Hver gang du kommer til en kanal, til M.Video-Eldorado-gruppen av selskaper, enten det er et nettsted eller en butikk, velger du et produkt der, se prisen på nettstedet eller i "Kurven", blir kostnaden automatisk beregnet av én tjeneste. Hvorfor er dette nødvendig: før dette hadde hvert system sine egne prinsipper for å jobbe med kampanjer - med rabatter og så videre. Vårt backoffice håndterer priser, rabattfunksjonalitet er implementert i et annet system. Dette måtte sentraliseres og en unik, separerbar tjeneste lages i form av en forretningsprosess som ville tillate oss å implementere dette. Det var omtrent slik vi startet.
Verdien av de første resultatene var veldig stor. For det første var vi i stand til å lage separerbare enheter som lar oss jobbe separat og på en aggregert måte. For det andre har vi redusert eierkostnadene når det gjelder integrasjon med flere systemer.
I løpet av de siste tre årene har vi lagt til tre frontlinjesystemer. Det var vanskelig å opprettholde dem med samme mengde ressurser som selskapet hadde råd til. Derfor oppsto oppgaven med å se etter nye utsalgssteder, svare på markedet når det gjelder hastighet, med tanke på interne kostnader og effektivitet.
Hvordan måle suksessen med å migrere til mikrotjenester
Dmitriy:
Hvordan bestemmes suksess med å migrere til mikrotjenester? Hva var "før" i hvert selskap? Hvilken beregning brukte du for å fastslå suksessen til overgangen, og hvem bestemte det egentlig?
Sergey:
Først av alt ble det født innen IT som en muliggjører - "å låse opp" nye evner. Vi hadde et behov for å gjøre alt raskere for relativt de samme pengene, og svare på markedsutfordringer. Nå kommer suksess til uttrykk i antall tjenester som gjenbrukes av forskjellige systemer, forening av prosesser seg imellom. Nå er det det, men i det øyeblikket var det en mulighet til å lage en plattform og bekrefte hypotesen om at vi kan gjøre dette, det vil gi effekt og beregne business case.
Alexander:
Suksess er snarere en indre følelse. Næringslivet vil alltid ha mer, og dybden i backlogen vår er et bevis på suksess. Det virker slik for meg.
Sergey:
Ja jeg er enig. På tre år har vi allerede mer enn to hundre tjenester og etterslep. Behovet for ressurser i teamet bare vokser – med 30 % årlig. Dette skjer fordi folk følte: det er raskere, det er annerledes, det er forskjellige teknologier, alt dette utvikler seg.
Mikrotjenester vil komme, men kjernen vil forbli
Dmitriy:
Det er som en uendelig prosess der du investerer i utvikling. Er overgangen til mikrotjenester for bedrifter allerede over eller ikke?
Sergey:
Det er veldig enkelt å svare på. Hva synes du: Å bytte ut telefoner er en endeløs prosess? Selv kjøper vi telefoner hvert år. Og her er det: så lenge det er behov for fart, for tilpasning til markedet, vil det kreves noen endringer. Dette betyr ikke at vi forlater standard ting.
Men vi kan ikke dekke og gjøre om alt på en gang. Vi har eldre, standard integrasjonstjenester som eksisterte før: bedriftsbusser og så videre. Men det er et etterslep, og det er også et behov. Antallet mobilapplikasjoner og deres funksjonalitet vokser. Samtidig er det ingen som sier at du får 30 % mer penger. Det vil si at det alltid er behov på den ene siden, og søken etter effektivitet på den andre.
Dmitriy:
Livet er i god form. (ler)
Alexander:
Generelt sett, ja. Vi har ikke revolusjonerende tilnærminger til å fjerne kjernedelen fra landskapet. Det pågår et systematisk arbeid for å dekomponere systemer slik at de er mer konsistente med mikrotjenestearkitektur, for å redusere systemenes påvirkning på hverandre.
Men vi planlegger å beholde kjernedelen, siden i operatørens landskap vil det alltid være noen plattformer vi kjøper. Igjen, vi trenger en sunn balanse: vi bør ikke skynde oss å kutte ut kjernen. Vi plasserer systemene side om side, og nå viser det seg at vi allerede er på toppen av mange kjernedeler. Videre, ved å utvikle funksjonaliteten, skaper vi de nødvendige representasjonene for alle kanaler som jobber med våre kommunikasjonstjenester.
Hvordan selge mikrotjenester til bedrifter
Dmitriy:
Jeg er også interessert - for de som ikke har byttet, men planlegger det: hvor lett var det å selge denne ideen til bedrifter og var det et eventyr, et investeringsprosjekt? Eller var det en bevisst strategi: nå skal vi til mikrotjenester og det er det, ingenting vil stoppe oss. Hvordan var det for deg?
Sergey:
Vi solgte ikke en tilnærming, men en forretningsfordel. Det var et problem i virksomheten, og vi prøvde å løse det. I det øyeblikket kom det til uttrykk i det faktum at forskjellige kanaler brukte forskjellige prinsipper for å beregne priser - separat for kampanjer, for kampanjer, og så videre. Det var vanskelig å vedlikeholde, det oppsto feil, og vi lyttet til kundeklager. Det vil si at vi solgte en løsning på et problem, men vi kom med at vi trengte penger for å lage en plattform. Og de viste en forretningscase ved å bruke eksemplet med den første fasen av investeringen: hvordan vi vil fortsette å tjene tilbake den og hva dette vil tillate oss å gjøre.
Dmitriy:
Registrerte du på en eller annen måte tidspunktet for den første etappen?
Sergey:
Ja sikkert. Vi bevilget 6 måneder til å lage kjernen som plattform og teste piloten. I løpet av denne tiden prøvde vi å lage en plattform for å skate piloten. Da ble hypotesen bekreftet, og siden den fungerer, betyr det at vi kan fortsette. De begynte å replikere og styrket laget - de flyttet det inn i en egen divisjon som gjør nettopp det.
Deretter kommer systematisk arbeid basert på virksomhetens behov, muligheter, tilgjengelighet på ressurser og alt som er i arbeid.
Dmitriy:
OK. Alexander, hva sier du?
Alexander:
Våre mikrotjenester ble født fra "havets skum" - på grunn av ressurssparing, på grunn av noen rester i form av serverkapasitet og omfordeling av krefter i teamet. I utgangspunktet solgte vi ikke dette prosjektet til bedrifter. Dette var et prosjekt hvor vi både undersøkte og utviklet oss deretter. Vi startet i begynnelsen av 2018 og utviklet rett og slett denne retningen med entusiasme. Salget har akkurat startet og vi er i gang.
Dmitriy:
Skjer det at en bedrift lar deg gjøre slike ting som Google – på én ledig dag i uken? Har du en slik retning?
Alexander:
Samtidig med forskning håndterte vi også forretningsproblemer, så alle våre mikrotjenester er løsninger på forretningsproblemer. Bare i begynnelsen bygde vi mikrotjenester som dekket en liten del av abonnentbasen, og nå er vi til stede i nesten alle flaggskipprodukter.
Og den materielle påvirkningen er allerede klar - vi kan allerede telles, hastigheten på produktlanseringer og tapte inntekter kan estimeres hvis vi hadde fulgt den gamle veien. Det er dette vi bygger saken på.
Mikrotjenester: hype eller nødvendighet?
Dmitriy:
Tall er tall. Og inntekter eller penger spart er veldig viktig. Hva om du ser på den andre siden? Det ser ut til at mikrotjenester er en trend, en hype og mange selskaper misbruker det? Hvor tydelig skiller du mellom hva du gjør og ikke oversetter til mikrotjenester? Hvis arv nå, vil du fortsatt ha arv om 5 år? Hvor gammel vil informasjonssystemene som fungerer hos M.Video-Eldorado og MegaFon være om 5 år? Kommer det ti år, femten år gamle informasjonssystemer eller blir det en ny generasjon? Hvordan ser du på dette?
Sergey:
For meg virker det som om det er vanskelig å tenke veldig langt unna. Hvis vi ser tilbake, hvem så for seg at teknologimarkedet ville utvikle seg på denne måten, inkludert maskinlæring og brukeridentifikasjon ved ansikt? Men hvis du ser på de kommende årene, ser det ut til at kjernesystemer, enterprise ERP-klasse systemer i bedrifter - de har fungert ganske lenge.
Våre selskaper er til sammen 25 år gamle, med klassisk ERP veldig dypt i systemlandskapet. Det er klart at vi tar noen deler ut derfra og prøver å samle dem til mikrotjenester, men kjernen vil forbli. Det er vanskelig for meg nå å forestille seg at vi skal erstatte alle kjernesystemene der og raskt gå over til den andre, lyse siden av de nye systemene.
Jeg er tilhenger av at alt som er nærmere kunden og forbrukeren er der den største forretningsnytten og verdien er, der tilpasningsevne og fokus på hastighet, på endring, på «prøve, avbryt, gjenbruk, gjør noe annerledes» er nødvendig "—det er der landskapet vil endre seg. Og eskeprodukter passer ikke så godt inn der. Vi ser det i hvert fall ikke. Der kreves de enkleste og enkleste løsningene.
Vi ser denne utviklingen:
- kjerneinformasjonssystemer (for det meste backoffice);
- mellomlag i form av mikrotjenester forbinder kjernen, samler, lager en cache og så videre;
- frontlinjesystemer er rettet mot forbrukeren;
- et integreringslag som generelt er integrert i markedsplasser, andre systemer og økosystemer. Dette laget er så lett som mulig, enkelt og inneholder et minimum av forretningslogikk.
Men jeg er samtidig tilhenger av å fortsette å bruke de gamle prinsippene dersom de brukes på en hensiktsmessig måte.
La oss si at du har et klassisk bedriftssystem. Den ligger i landskapet til én leverandør og består av to moduler som fungerer med hverandre. Det er også et standard integrasjonsgrensesnitt. Hvorfor gjøre om det og ta med en mikrotjeneste dit?
Men når det er 5 moduler i backoffice, hvorfra deler av informasjon samles inn i en forretningsprosess, som deretter brukes av 8-10 frontlinjesystemer, er fordelen umiddelbart merkbar. Du tar fra fem back-office-systemer og lager en tjeneste, en isolert, som er fokusert på forretningsprosessen. Gjør tjenesten teknologisk avansert – slik at den cacher informasjon og er feiltolerant, og også fungerer med dokumenter eller forretningsenheter. Og du integrerer den i henhold til ett enkelt prinsipp med alle frontlinjeprodukter. De kansellerte frontlinjeproduktet – de slo rett og slett av integrasjonen. I morgen må du skrive en mobilapplikasjon eller lage en liten nettside og sette bare en del inn i funksjonalitet - alt er enkelt: du satte det sammen som en konstruktør. Jeg ser mer utvikling i denne retningen – i hvert fall i vårt land.
Alexander:
Sergey beskrev helt vår tilnærming, takk. Jeg vil bare si hvor vi definitivt ikke vil gå - til kjernedelen, til temaet nettfakturering. Det vil si at vurdering og lading forblir faktisk en "stor" tresker som pålitelig vil avskrive penger. Og dette systemet vil fortsatt være sertifisert av våre tilsynsmyndigheter. Alt annet som ser mot klienter, er selvfølgelig mikrotjenester.
Dmitriy:
Her er sertifisering én historie. Sannsynligvis mer støtte. Hvis du bruker lite på støtte eller systemet ikke krever støtte og modifikasjon, er det bedre å ikke røre det. Et fornuftig kompromiss.
Hvordan utvikle pålitelige mikrotjenester
Dmitriy:
Fint. Men jeg er fortsatt interessert. Nå forteller du en suksesshistorie: alt var bra, vi byttet til mikrotjenester, forsvarte ideen til virksomheten, og alt ordnet seg. Men jeg har hørt andre historier.
For et par år siden avsluttet et sveitsisk selskap som hadde investert to år i å utvikle en ny mikrotjenesteplattform for banker prosjektet. Helt kollapset. Mange millioner sveitsiske franc ble brukt, og til slutt ble teamet spredt - det gikk ikke.
Har du hatt lignende historier? Var eller er det noen vanskeligheter? For eksempel er vedlikehold av mikrotjenester og overvåking også en hodepine i selskapets operasjonelle aktiviteter. Tross alt øker antall komponenter titalls ganger. Hvordan ser du på det, har det vært mislykkede eksempler på investeringer her? Og hva kan du råde folk til slik at de ikke støter på slike problemer?
Alexander:
Mislykkede eksempler inkluderer virksomheter som endret prioriteringer og kansellerte prosjekter. På et godt stadium av beredskap (faktisk MVP er klar), sa virksomheten: "Vi har nye prioriteringer, vi går videre til et annet prosjekt, og vi avslutter dette."
Vi hadde ingen globale feil med mikrotjenester. Vi sover fredelig, vi har et vakthold 24/7 som betjener hele BSS [forretningsstøttesystemet].
Og en ting til – vi leier ut mikrotjenester etter reglene som gjelder for eskeprodukter. Nøkkelen til suksess er at du for det første må sette sammen et team som fullt ut skal forberede mikrotjenesten for produksjon. Selve utbyggingen er betinget på 40 %. Resten er analyser, DevSecOps-metodikk, riktige integrasjoner og riktig arkitektur. Vi legger spesiell vekt på prinsippene for å bygge sikre applikasjoner. Informasjonssikkerhetsrepresentanter deltar i hvert prosjekt både på arkitekturplanleggingsstadiet og under implementeringsprosessen. De administrerer også systemer for å analysere kode for sårbarheter.
La oss si at vi distribuerer våre statsløse tjenester – vi har dem i Kubernetes. Dette gjør at alle kan sove rolig på grunn av automatisk skalering og automatisk heving av tjenester, og vaktskiftet tar opp hendelser.
I hele eksistensen av våre mikrotjenester har det bare vært en eller to hendelser som har nådd vår linje. Nå er det ingen problemer med driften. Vi har selvfølgelig ikke 200, men rundt 50 mikrotjenester, men de brukes i flaggskipprodukter. Hvis de mislyktes, ville vi være de første til å få vite om det.
Microservices og HR
Sergey:
Jeg er enig med min kollega om overgangen til støtte - at arbeidet må organiseres riktig. Men jeg skal fortelle deg om problemene som selvfølgelig finnes.
For det første er teknologien ny. Dette er hype på en god måte, og å finne en spesialist som forstår og kan skape dette er en stor utfordring. Konkurransen om ressursene er vanvittig, så eksperter er gull verdt.
For det andre, med opprettelsen av visse landskap og et økende antall tjenester, må problemet med gjenbruk hele tiden løses. Som utviklere liker å gjøre: "La oss skrive mange interessante ting her nå ..." På grunn av dette vokser systemet og mister sin effektivitet i form av penger, eierkostnader og så videre. Det vil si at det er nødvendig å inkludere gjenbruk i systemarkitekturen, inkludere det i veikartet for å introdusere tjenester og overføre arv til en ny arkitektur.
Et annet problem – selv om dette er bra på sin måte – er intern konkurranse. "Å, nye fasjonable gutter har dukket opp her, de snakker et nytt språk." Folk er selvfølgelig forskjellige. Det er de som er vant til å skrive i Java, og de som skriver og bruker Docker og Kubernetes. Dette er helt forskjellige mennesker, de snakker forskjellig, bruker forskjellige begreper og forstår noen ganger ikke hverandre. Evnen eller manglende evnen til å dele praksis, kunnskapsdeling, i denne forstand er også et problem.
Vel, skalering av ressurser. «Flott, la oss gå! Og nå vil vi ha raskere, mer. Hva, kan du ikke? Er det ikke mulig å levere dobbelt så mye på et år? Og hvorfor?" Slike voksesmerter er nok standard for mange ting, mange tilnærminger, og du kan føle dem.
Angående overvåking. Det virker for meg som om tjenester eller industrielle overvåkingsverktøy allerede lærer eller er i stand til å jobbe med både Docker og Kubernetes i en annen, ikke-standard modus. Slik at du for eksempel ikke ender opp med 500 Java-maskiner som alt dette kjører under, nemlig det samler seg. Men disse produktene mangler fortsatt modenhet, de må gjennom dette. Temaet er virkelig nytt, det vil fortsette å utvikle seg.
Dmitriy:
Ja, veldig interessant. Og dette gjelder HR. Kanskje din HR-prosess og HR-merke har endret seg litt i løpet av disse 3 årene. Du begynte å rekruttere andre mennesker med annen kompetanse. Og det er nok både fordeler og ulemper. Tidligere var blockchain og datavitenskap hypen, og spesialister på dem var verdt millioner. Nå faller kostnadene, markedet blir mettet, og det er en lignende trend innen mikrotjenester.
Sergey:
Ja absolutt.
Alexander:
HR stiller spørsmålet: "Hvor er din rosa enhjørning mellom backend og frontend?" HR forstår ikke hva en mikrotjeneste er. Vi fortalte dem hemmeligheten og fortalte dem at backend gjorde alt, og det er ingen enhjørning. Men HR er i endring, lærer raskt og rekrutterer folk som har grunnleggende IT-kunnskaper.
Utviklingen av mikrotjenester
Dmitriy:
Hvis du ser på målarkitekturen, ser mikrotjenester ut som et slikt monster. Reisen din tok flere år. Andre har ett år, andre tre år. Forutså du alle problemene, målarkitekturen, endret noe seg? For eksempel, når det gjelder mikrotjenester, vises nå gatewayer og servicemasker igjen. Brukte du dem i begynnelsen eller endret du selve arkitekturen? Har du slike utfordringer?
Sergey:
Vi har allerede skrevet om flere kommunikasjonsprotokoller. Først var det én protokoll, nå gikk vi over til en annen. Vi øker sikkerheten og påliteligheten. Vi startet med bedriftsteknologier – Oracle, Web Logic. Nå går vi bort fra teknologiske bedriftsprodukter innen mikrotjenester og går over til åpen kildekode eller helt åpne teknologier. Vi forlater databaser og går over til det som fungerer mer effektivt for oss i denne modellen. Vi trenger ikke lenger Oracle-teknologier.
Vi startet rett og slett som en tjeneste, uten å tenke på hvor mye vi trengte en cache, hva vi ville gjøre når det ikke var noen forbindelse med en mikrotjeneste, men det var behov for data osv. Nå utvikler vi en plattform slik at arkitekturen kan beskrives ikke på tjenestespråket, og på forretningsspråk, ta forretningslogikk til neste nivå når vi begynner å snakke i ord. Nå har vi lært å snakke i bokstaver, og neste nivå er når tjenestene skal samles i en slags aggregat, når dette allerede er et ord – for eksempel et helt produktkort. Det er satt sammen fra mikrotjenester, men det er et API bygget på toppen av dette.
Sikkerhet er veldig viktig. Så snart du begynner å være tilgjengelig og du har en tjeneste som du kan få mange interessante ting gjennom, og veldig raskt, på et brøkdel av et sekund, så er det et ønske om å få det på en ikke den sikreste måten. For å komme vekk fra dette måtte vi endre tilnærminger til testing og overvåking. Vi måtte endre teamet, leveransestyringsstrukturen, CI/CD.
Dette er en utvikling - som med telefoner, bare mye raskere: først var det trykkknapptelefoner, så dukket det opp smarttelefoner. De skrev om og redesignet produktet fordi markedet hadde et annet behov. Slik utvikler vi oss: første klasse, tiende klasse, jobb.
Iterativt legges det opp noe per år ut fra et teknologisk synspunkt, noe annet ut fra etterslep og behov. Vi kobler en ting til en annen. Teamet bruker 20 % på teknisk gjeld og teknisk støtte for teamet, 80 % på forretningsenheten. Og vi beveger oss med en forståelse av hvorfor vi gjør det, hvorfor vi gjør disse teknologiske forbedringene, hva de vil føre til. Slik.
Dmitriy:
Kul. Hva er i MegaFon?
Alexander:
Hovedutfordringen når vi kom til mikrotjenester var å ikke falle i kaos. Arkitektkontoret til MegaFon ble umiddelbart med oss, ble til og med initiativtaker og driver - nå har vi en veldig sterk arkitektur. Hans oppgave var å forstå hvilken målmodell vi skal til og hvilke teknologier som må piloteres. Med arkitektur gjennomførte vi disse pilotene selv.
Det neste spørsmålet var: "Hvordan kan vi utnytte alt dette?" Og en til: "Hvordan sikre transparent interaksjon mellom mikrotjenester?" Service mesh hjalp oss med å svare på det siste spørsmålet. Vi testet Istio og likte resultatene. Nå er vi i ferd med å rulle ut i produktive soner. Vi har en positiv holdning til alle utfordringer – det faktum at vi hele tiden må endre stabelen, lære noe nytt. Vi er interessert i å utvikle, ikke utnytte gamle løsninger.
Dmitriy:
Gullord! Slike utfordringer holder teamet og virksomheten på tå hev og skaper fremtiden. GDPR opprettet databeskyttelsessjefer, og nåværende utfordringer skaper sjefer for mikrotjenester og arkitektur. Og det gleder.
Vi diskuterte mye. Hovedsaken er at en god design av mikrotjenester og selve arkitekturen lar deg unngå mange feil. Selvfølgelig er prosessen iterativ og evolusjonær, men det er fremtiden.
Takk til alle deltakere, takk til Sergei og Alexander!
Spørsmål fra salen
Spørsmål fra salen (1):
Sergey, hvordan har IT-ledelsen endret seg i bedriften din? Jeg forstår at når det er en stor stabel med flere systemer, er hvordan det administreres en ganske klar og logisk prosess. Hvordan gjenoppbygde du styringen av IT-komponenten etter at et veldig stort antall mikrotjenester ble integrert på så kort tid?
Sergey:
Jeg er enig med kollegaen min i at arkitektur er veldig viktig som pådriver for endring. Vi startet med å ha en arkitektonisk inndeling. Arkitekter er samtidig eiere av funksjonsfordelingen og kravene til hvordan den skal fremstå i landskapet. Så de fungerer også som koordinatorer for disse endringene. Som et resultat ble det spesifikke endringer i en spesifikk leveringsprosess da vi opprettet en CI/CD-plattform.
Men standarden, grunnleggende prinsipper for utvikling, forretningsanalyse, testing og utvikling er ikke kansellert. Vi har nettopp lagt til fart. Tidligere tok syklusen så mye, installasjon på testmiljøer tok så mye mer. Nå ser næringslivet fordelen og sier: "Hvorfor kan vi ikke gjøre det samme andre steder?"
Det er som, på en god måte, en injeksjon i form av en vaksine som viste: du kan gjøre det på denne måten, men du kan gjøre det på en annen måte. Selvfølgelig er det et problem i personell, i kompetanser, i kunnskap, i motstand.
Spørsmål fra salen (2):
Kritikere av mikrotjenestearkitektur sier at testing og utvikling er vanskelig. Dette er logisk der ting blir komplisert. Hvilke utfordringer møtte teamet ditt og hvordan overvant du dem? Spørsmål til alle.
Alexander:
Det er vanskeligheter når du flytter fra mikrotjenester til en plattform, men de kan løses.
For eksempel lager vi et produkt som består av 5-7 mikrotjenester. Vi må tilby integrasjonstester på tvers av hele mikrotjenestestabelen for å gi grønt lys for å flytte til hovedgrenen. Denne oppgaven var ikke ny for oss: vi hadde gjort dette lenge på BSS, da leverandøren forsynte oss med allerede leverte løsninger.
Og problemet vårt er bare i det lille laget. En QA-ingeniør er nødvendig for ett betinget produkt. Og så sender vi et produkt på 5-7 mikrotjenester, hvorav 2-3 kan utvikles av tredjeparter. For eksempel har vi et produkt i utviklingen hvor leverandøren av faktureringssystem, Mail.ru Group og MegaFon R&D deltar. Vi må dekke dette med tester før vi sender det til produksjon. QA-ingeniøren har jobbet med dette produktet i halvannen måned, og resten av teamet står uten hans støtte.
Denne kompleksiteten er bare forårsaket av skalering. Vi forstår at mikrotjenester ikke kan eksistere i et vakuum; absolutt isolasjon eksisterer ikke. Ved endring av en tjeneste prøver vi alltid å bevare API-kontrakten. Hvis noe endres under panseret, gjenstår frontservicen. Hvis endringene er fatale, skjer en eller annen form for arkitektonisk transformasjon og vi går over til en helt annen datametamodell, som er helt uforenlig – først da snakker vi om at v2-tjenestens API-spesifikasjon dukker opp. Vi støtter den første og andre versjonen samtidig, og etter at alle forbrukere bytter til den andre versjonen, lukker vi bare den første.
Sergey:
Jeg vil legge til. Jeg er helt enig om komplikasjoner - de skjer. Landskapet blir mer komplekst, og overheadkostnadene øker, spesielt for testing. Slik takler du dette: bytt til automatisert testing. Ja, du må investere i tillegg i å skrive autotester og enhetstester. For at utviklere ikke kunne forplikte seg uten å bestå testen, kunne de ikke endre koden. Slik at selv trykknappen ikke fungerer uten autotest, enhetstest.
Det er viktig å opprettholde den tidligere funksjonaliteten, og dette er ekstra overhead. Hvis du skriver om en teknologi til en annen protokoll, så skriver du den om til du lukker alt helt.
Noen ganger gjør vi ikke ende-til-ende-testing med vilje, fordi vi ikke ønsker å stoppe utviklingen, selv om vi også har det ene etter det andre. Landskapet er veldig stort, komplekst, det er mange systemer. Noen ganger er det bare stubber - ja, du senker sikkerhetsmarginen, flere risikoer dukker opp. Men samtidig slipper du forsyningen.
Alexander:
Ja, autotester og enhetstester lar deg lage en tjeneste av høy kvalitet. Vi er for en rørledning som ikke kan bestås uten enhets- og integrasjonstester. Vi må ofte dra emulatorer og kommersielle systemer inn i testsoner og utviklingsmiljøer, fordi ikke alle systemer kan plasseres i testsoner. Dessuten blir de ikke bare våte - vi genererer en fullverdig respons fra systemet. Dette er en seriøs del av arbeidet med mikrotjenester, og vi satser også på det. Uten dette vil det oppstå kaos.
Spørsmål fra salen (3):
Så vidt jeg forstår, vokste mikrotjenester i utgangspunktet fra et eget team og eksisterer nå i denne modellen. Hva er dens fordeler og ulemper?
Vi har bare en lignende historie: en slags mikroservicefabrikk oppsto. Nå har vi konseptuelt kommet til det punktet at vi utvider denne tilnærmingen til produksjon etter strømmer og etter systemer. Vi beveger oss med andre ord bort fra den sentraliserte utviklingen av mikrotjenester, mikrotjenestemodeller, og nærmer oss systemer.
Følgelig går vår drift også til systemer, det vil si at vi desentraliserer dette emnet. Hva er din tilnærming og hva er målhistorien din?
Alexander:
Du droppet navnet "microservices factory" rett ut av munnen - vi ønsker også å skalere. For det første har vi egentlig ett lag nå. Vi ønsker å gi alle utviklingsteam som MegaFon har muligheten til å jobbe i et felles økosystem. Vi ønsker ikke å fullstendig overta all utviklingsfunksjonaliteten vi har nå. Den lokale oppgaven er å skalere, den globale oppgaven er å lede utviklingen til alle teamene i mikroservicelaget.
Sergey:
Jeg skal fortelle deg veien vi har tatt. Vi begynte egentlig å jobbe som ett team, men nå er vi ikke alene. Jeg er en tilhenger av følgende: det må være en eier av prosessen. Noen trenger å forstå, administrere, kontrollere og bygge utviklingsprosessen for mikrotjenester. Han må eie ressurser og drive med ressursforvaltning.
Disse ressursene, som kjenner teknologier, spesifikasjoner og forstår hvordan man bygger mikrotjenester, kan lokaliseres i produktteam. Vi har en blanding der folk fra mikroserviceplattformen er i produktteamet som lager mobilapplikasjonen. De er der, men de jobber i henhold til prosessen til avdelingen for administrasjon av mikroserviceplattformer med utviklingssjefen deres. Innenfor denne divisjonen er det et eget team som driver med teknologi. Det vil si at vi blander en felles pool av ressurser mellom oss og deler dem, og gir dem til team.
Samtidig forblir prosessen generell, kontrollert, den fortsetter i henhold til generelle teknologiske prinsipper, med enhetstesting og så videre - alt som er bygget på toppen. Det kan være kolonner i form av ressurser samlet inn fra ulike avdelinger av produkttilnærmingen.
Alexander:
Sergey, du er faktisk eieren av prosessen, ikke sant? Er oppgaveetterslepet delt? Hvem er ansvarlig for distribusjonen?
Sergey:
Se: her er blandingen igjen. Det er et etterslep som dannes basert på teknologiske forbedringer - dette er én historie. Det er et etterslep, som er formulert fra prosjekter, og det er et etterslep fra produkter. Men sekvensen for introduksjon i hvert av tjenesteproduktene eller opprettelsen av denne tjenesten er utviklet av en produktspesialist. Han er ikke i IT-direktoratet, han ble spesielt fjernet fra det. Men folkene mine jobber definitivt etter den samme prosessen.
Eieren av etterslepet i forskjellige retninger - etterslepet av endringer - vil være forskjellige mennesker. Tilkoblingen av teknologiske tjenester, deres organiseringsprinsipp - alt dette vil være i IT. Jeg eier plattformen og ressursene også. Øverst er det som gjelder etterslep og funksjonsendringer, og arkitekturen i denne forstand.
La oss si at en bedrift sier: "Vi vil ha denne funksjonen, vi ønsker å lage et nytt produkt - gjenskape et lån." Vi svarer: "Ja, vi gjør det på nytt." Arkitekter sier: "La oss tenke: hvor i lånet vil vi skrive mikrotjenester og hvordan vil vi gjøre det?" Så bryter vi det ned i prosjekter, produkter eller en teknologistabel, legger det inn i team og implementerer det. Har du laget et produkt internt og bestemt deg for å bruke mikrotjenester i dette produktet? Vi sier: "Nå må de eldre systemene vi hadde, eller frontlinjesystemene, bytte til disse mikrotjenestene." Arkitektene sier: "Så: i det teknologiske etterslepet i frontlinjeproduktene - overgangen til mikrotjenester. Gå". Og produktspesialister eller bedriftseiere forstår hvor mye kapasitet som er tildelt, når det skal gjøres og hvorfor.
Slutten på diskusjonen, men ikke alle
Mailto:CLOUD-konferansen ble arrangert .
Vi gjør også andre arrangementer – f.eks. @Kubernetes Meetup, hvor vi alltid ser etter gode foredragsholdere:
- Følg @Kubernetes og andre @Meetup-nyheter i vår Telegram-kanal
- Interessert i å snakke på en av @Meetups? Legg igjen en forespørsel om
Kilde: www.habr.com