Den 25. april holdt vi i Mail.ru Group en konference om skyer og omkring - . Et par højdepunkter:
- Det vigtigste — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center og Yandex.Cloud talte om de særlige forhold ved vores cloud-marked og deres tjenester;
- Kolleger fra Bitrix24 fortalte, hvordan de ;
- Leroy Merlin, Otkritie, Burger King og Schneider Electric leverede interessant — hvilke opgaver deres virksomhed sætter for IT, og hvilke teknologier, herunder cloud, ser de som de mest lovende.
Du kan se alle videoer fra mailto:CLOUD-konferencen , og her kan du læse, hvordan diskussionen om mikrotjenester gik. Alexander Deulin, leder af MegaFons forsknings- og udviklingscenter for forretningssystemer, og Sergey Sergeev, informationsteknologidirektør for M.Video-Eldorado-gruppen, delte deres succesfulde sager om at slippe af med monolitter. Vi diskuterede også relaterede spørgsmål om it-strategi, processer og endda HR.
Paneldeltagere
- Sergey Sergeev, Group CIO "M.Video-Eldorado";
- Alexander Deulin, leder af center for forskning og udvikling af forretningssystemer MegaFon;
- Moderator - Dmitry Lazarenko, Leder af PaaS-retning Mail.ru Cloud-løsninger.
Efter Alexander Deulins tale Sergey Sergeev fra M.Video-Eldorado og diskussionsmoderator Dmitry Lazarenko, Mail.ru Cloud Solutions, deltager i diskussionen.
Nedenfor har vi udarbejdet et udskrift af diskussionen til dig, men du kan også se videoen:
Overgangen til mikrotjenester er et svar på markedets behov
Dmitrij:
Har du haft succes med at migrere til mikrotjenester? Og generelt: Hvor ser du den største forretningsmæssige fordel ved at bruge mikrotjenester eller at gå fra monolitter til mikrotjenester?
Sergey:
Vi er allerede nået et stykke vej i overgangen til mikrotjenester og har brugt denne tilgang i mere end tre år. Det første behov, der retfærdiggjorde behovet for mikrotjenester, var den endeløse integration af forskellige front-end-produkter med backoffice. Og hver gang blev vi tvunget til at gøre yderligere integration og udvikling, implementere vores egne regler for driften af denne eller den service.
På et tidspunkt indså vi, at vi var nødt til at fremskynde driften af vores systemer og outputtet af funktionalitet. På det tidspunkt eksisterede begreber som mikrotjenester og en mikroservicetilgang allerede på markedet, og vi besluttede at prøve det. Dette startede i 2016. Derefter blev platformen lagt, og de første 10 tjenester blev implementeret af et separat team.
En af de første tjenester, den mest belastede, var prisberegningstjenesten. Hver gang du kommer til en kanal, til M.Video-Eldorado-gruppen af virksomheder, det være sig en hjemmeside eller en detailbutik, vælg et produkt der, se prisen på hjemmesiden eller i "Kurven", er prisen automatisk beregnet af én tjeneste. Hvorfor er dette nødvendigt: Før dette havde hvert system sine egne principper for at arbejde med kampagner - med rabatter og så videre. Vores backoffice håndterer prisfastsættelse; rabatfunktionalitet er implementeret i et andet system. Dette skulle centraliseres, og der skulle skabes en unik, adskillelig service i form af en forretningsproces, der ville give os mulighed for at implementere dette. Det var stort set sådan, vi startede.
Værdien af de første resultater var meget stor. For det første var vi i stand til at skabe adskillelige enheder, der giver os mulighed for at arbejde separat og på en aggregeret måde. For det andet har vi reduceret ejeromkostningerne i form af integration med flere systemer.
I løbet af de seneste tre år har vi tilføjet tre frontline-systemer. Det var svært at opretholde dem med samme mængde ressourcer, som virksomheden havde råd til. Derfor opstod opgaven med at lede efter nye afsætningsmuligheder, der reagerede på markedet med hensyn til hastighed, med hensyn til interne omkostninger og effektivitet.
Sådan måles succesen med at migrere til mikrotjenester
Dmitrij:
Hvordan bestemmes succes med at migrere til mikrotjenester? Hvad var "før" i hver virksomhed? Hvilken metrik brugte du til at bestemme succesen af overgangen, og hvem bestemte det egentlig?
Sergey:
Først og fremmest blev det født inden for IT som en muliggører - "låse op" for nye muligheder. Vi havde et behov for at gøre alting hurtigere for relativt de samme penge og reagere på markedsudfordringer. Nu kommer succes til udtryk i antallet af tjenester, der genbruges af forskellige systemer, forening af processer indbyrdes. Nu er det, men i det øjeblik var det en mulighed for at skabe en platform og bekræfte hypotesen om, at vi kan gøre dette, det vil give en effekt og beregne business casen.
Alexander:
Succes er snarere en indre følelse. Virksomheden vil altid have mere, og dybden af vores efterslæb er bevis på succes. Det forekommer mig sådan.
Sergey:
Ja jeg er enig. På tre år har vi allerede mere end to hundrede tjenester og efterslæb. Behovet for ressourcer i teamet vokser kun - med 30% årligt. Dette sker, fordi folk følte: det er hurtigere, det er anderledes, der er forskellige teknologier, alt dette er under udvikling.
Mikrotjenester vil komme, men kernen forbliver
Dmitrij:
Det er som en uendelig proces, hvor man investerer i udvikling. Er overgangen til mikrotjenester for virksomheder allerede overstået eller ej?
Sergey:
Det er meget nemt at svare på. Hvad synes du: at udskifte telefoner er en endeløs proces? Vi køber selv telefoner hvert år. Og her er det: Så længe der er behov for hastighed, for tilpasning til markedet, vil der være behov for nogle ændringer. Det betyder ikke, at vi opgiver standardting.
Men vi kan ikke dække og lave alt om på én gang. Vi har ældre standardintegrationstjenester, der eksisterede før: virksomhedsbusser og så videre. Men der er et efterslæb, og der er også et behov. Antallet af mobilapplikationer og deres funktionalitet vokser. Samtidig er der ingen, der siger, at du får 30 % flere penge. Det vil sige, at der altid er behov på den ene side, og en søgen efter effektivitet på den anden.
Dmitrij:
Livet er i god form. (griner)
Alexander:
Generelt, ja. Vi har ikke revolutionerende tilgange til at fjerne kernedelen fra landskabet. Der arbejdes systematisk med at nedbryde systemer, så de er mere konsistente med mikroservicearkitektur, for at reducere systemernes indflydelse på hinanden.
Men vi planlægger at beholde kernedelen, da der i operatørens landskab altid vil være nogle platforme, som vi køber. Igen har vi brug for en sund balance: vi skal ikke skynde os at skære kernen ud. Vi placerer systemerne side om side, og nu viser det sig, at vi allerede er oven på mange kernedele. Med videreudvikling af funktionaliteten skaber vi de nødvendige repræsentationer for alle kanaler, der arbejder med vores kommunikationstjenester.
Sådan sælger du mikrotjenester til virksomheder
Dmitrij:
Jeg er også interesseret - for dem, der ikke har skiftet, men planlægger at: hvor let var det at sælge denne idé til erhvervslivet, og var det et eventyr, et investeringsprojekt? Eller var det en bevidst strategi: nu skal vi til mikrotjenester, og det er det, intet vil stoppe os. Hvordan var det for dig?
Sergey:
Vi solgte ikke en tilgang, men en forretningsmæssig fordel. Der var et problem i erhvervslivet, og vi forsøgte at løse det. På det tidspunkt kom det til udtryk i, at forskellige kanaler brugte forskellige principper til at beregne priser - separat for kampagner, til kampagner og så videre. Det var svært at vedligeholde, der opstod fejl, og vi lyttede til kundernes klager. Det vil sige, at vi solgte en løsning på et problem, men vi kom med, at vi havde brug for penge til at skabe en platform. Og de viste en business case ved at bruge eksemplet med den første fase af investeringen: hvordan vi vil fortsætte med at inddrive den, og hvad det vil give os mulighed for.
Dmitrij:
Optog du på en eller anden måde tidspunktet for første etape?
Sergey:
Ja sikkert. Vi afsatte 6 måneder til at skabe kernen som platform og teste piloten. I løbet af denne tid forsøgte vi at skabe en platform, hvorpå vi kunne skate piloten. Så blev hypotesen bekræftet, og da den virker, betyder det, at vi kan fortsætte. De begyndte at replikere og styrkede holdet - de flyttede det ind i en separat division, der gør netop det.
Dernæst kommer systematisk arbejde baseret på forretningsbehov, muligheder, tilgængelighed af ressourcer og alt, hvad der lige nu er på vej.
Dmitrij:
OKAY. Alexander, hvad siger du?
Alexander:
Vores mikrotjenester blev født af "havets skum" - på grund af ressourcebesparelser, på grund af nogle rester i form af serverkapacitet og omfordeling af kræfter i teamet. I første omgang solgte vi ikke dette projekt til erhvervslivet. Dette var et projekt, hvor vi både undersøgte og udviklede os derefter. Vi startede i begyndelsen af 2018 og udviklede simpelthen denne retning med entusiasme. Salget er lige begyndt, og vi er i gang.
Dmitrij:
Sker det, at en virksomhed giver dig mulighed for at gøre sådanne ting efter Google-princippet - på én ledig dag om ugen? Har du sådan en retning?
Alexander:
Samtidig med forskning beskæftigede vi os også med forretningsproblemer, så alle vores mikrotjenester er løsninger på forretningsproblemer. Kun i begyndelsen byggede vi mikrotjenester, der dækkede en lille del af abonnentbasen, og nu er vi til stede i næsten alle flagskibsprodukter.
Og den materielle påvirkning er allerede klar - vi kan allerede tælles, hastigheden af produktlanceringer og tabt omsætning kan estimeres, hvis vi havde fulgt den gamle vej. Det er det, vi bygger sagen på.
Mikrotjenester: hype eller nødvendighed?
Dmitrij:
Tal er tal. Og omsætning eller sparede penge er meget vigtigt. Hvad hvis du ser på den anden side? Det ser ud til, at mikrotjenester er en trend, en hype og mange virksomheder misbruger det? Hvor tydeligt skelner du mellem, hvad du gør og ikke oversætter til mikrotjenester? Hvis arv nu, vil du så stadig have arv om 5 år? Hvad er alderen på de informationssystemer, der fungerer hos M.Video-Eldorado og MegaFon om 5 år? Kommer der ti år, femten år gamle informationssystemer, eller bliver det en ny generation? Hvordan ser du dette?
Sergey:
Det forekommer mig, at det er svært at tænke meget langt væk. Hvis vi ser tilbage, hvem forestillede sig, at teknologimarkedet ville udvikle sig på denne måde, herunder maskinlæring og brugeridentifikation ved ansigt? Men hvis man ser på de kommende år, forekommer det mig, at kernesystemer, enterprise ERP-klasse systemer i virksomheder - de har fungeret i ret lang tid.
Vores virksomheder er tilsammen 25 år gamle, med klassisk ERP meget dybt i systemlandskabet. Det er klart, at vi tager nogle stykker derfra og forsøger at samle dem til mikrotjenester, men kernen vil forblive. Det er svært for mig nu at forestille mig, at vi vil udskifte alle kernesystemerne der og hurtigt flytte til den anden, lyse side af de nye systemer.
Jeg er tilhænger af, at alt, hvad der er tættere på kunden og forbrugeren, er dér, hvor den største forretningsmæssige fordel og værdi er, hvor tilpasningsevne og fokus på hurtighed, på forandring, på "prøv, annuller, genbrug, gør noget andet" er. tiltrængt "-det er her, landskabet vil ændre sig. Og æskeprodukter passer ikke særlig godt ind der. Vi ser det i hvert fald ikke. Der kræves de nemmeste, enkleste løsninger.
Vi ser denne udvikling:
- kerneinformationssystemer (for det meste backoffice);
- mellemlag i form af mikrotjenester forbinder kernen, samler, laver en cache og så videre;
- frontlinjesystemer er rettet mod forbrugeren;
- et integrationslag, der generelt er integreret i markedspladser, andre systemer og økosystemer. Dette lag er så let som muligt, enkelt og indeholder et minimum af forretningslogik.
Men jeg er samtidig tilhænger af, at de gamle principper fortsat skal bruges, hvis de bliver brugt hensigtsmæssigt.
Lad os sige, at du har et klassisk virksomhedssystem. Det er placeret i én leverandørs landskab og består af to moduler, der arbejder med hinanden. Der er også en standard integrationsgrænseflade. Hvorfor lave det om og bringe en mikroservice dertil?
Men når der er 5 moduler i backoffice, hvorfra informationer samles ind i en forretningsproces, som så bruges af 8-10 frontline-systemer, er fordelen umiddelbart mærkbar. Du tager fra fem back-office-systemer og skaber en service, en isoleret, der er fokuseret på forretningsprocessen. Gør tjenesten teknologisk avanceret - så den cacher information og er fejltolerant, og også fungerer med dokumenter eller forretningsenheder. Og du integrerer det efter et enkelt princip med alle front-line produkter. De annullerede frontline-produktet – de slog simpelthen integrationen fra. I morgen skal du skrive en mobilapplikation eller lave en lille hjemmeside og kun sætte en del ind i funktionalitet - alt er enkelt: du har samlet det som en konstruktør. Jeg ser mere udvikling i denne retning – i hvert fald i vores land.
Alexander:
Sergey beskrev fuldstændig vores tilgang, tak. Jeg vil bare sige, hvor vi bestemt ikke vil gå - til kernedelen, til emnet online fakturering. Det vil sige, vurdering og opkrævning vil i virkeligheden forblive en "stor" tærskemaskine, der pålideligt vil afskrive penge. Og dette system vil fortsat være certificeret af vores regulerende myndigheder. Alt andet, der retter sig mod kunder, er selvfølgelig mikrotjenester.
Dmitrij:
Her er certificering én historie. Sandsynligvis mere støtte. Hvis du bruger lidt på support eller systemet ikke kræver support og modifikation, er det bedre ikke at røre ved det. Et fornuftigt kompromis.
Hvordan man udvikler pålidelige mikrotjenester
Dmitrij:
Bøde. Men jeg er stadig interesseret. Nu fortæller du en succeshistorie: alt var fint, vi skiftede til mikrotjenester, forsvarede ideen over for virksomheden, og alt fungerede. Men jeg har hørt andre historier.
For et par år siden lukkede en schweizisk virksomhed, der havde investeret to år i at udvikle en ny mikroserviceplatform til banker, projektet. Fuldstændig kollapset. Mange millioner schweizerfranc blev brugt, og til sidst blev holdet spredt - det lykkedes ikke.
Har du haft lignende historier? Var eller er der nogle vanskeligheder? For eksempel er vedligeholdelse af mikrotjenester og overvågning også en hovedpine i virksomhedens operationelle aktiviteter. Når alt kommer til alt, stiger antallet af komponenter titusindvis af gange. Hvordan ser du det, har der været mislykkede eksempler på investeringer her? Og hvad kan du råde folk til, så de ikke støder på sådanne problemer?
Alexander:
Mislykkede eksempler omfattede virksomheder, der ændrede prioriteter og aflyste projekter. Da virksomheden var på et godt beredskab (faktisk er MVP klar), sagde virksomheden: "Vi har nye prioriteter, vi går videre til et andet projekt, og vi lukker dette."
Vi havde ingen globale fejl med mikrotjenester. Vi sover roligt, vi har en vagt 24/7, der servicerer hele BSS [forretningssupportsystemet].
Og en ting mere - vi udlejer mikroservices efter de regler, der gælder for æskeprodukter. Nøglen til succes er, at du for det første skal sammensætte et team, der fuldt ud forbereder mikroservicen til produktion. Selve udviklingen er betinget 40%. Resten er analyser, DevSecOps-metodologi, de rigtige integrationer og den rigtige arkitektur. Vi er særligt opmærksomme på principperne for at bygge sikre applikationer. Informationssikkerhedsrepræsentanter deltager i hvert projekt både på arkitekturplanlægningsstadiet og under implementeringsprocessen. De administrerer også systemer til analyse af kode for sårbarheder.
Lad os sige, at vi implementerer vores statsløse tjenester – vi har dem i Kubernetes. Dette giver alle mulighed for at sove roligt på grund af automatisk skalering og automatisk hævning af tjenester, og vagtskiftet opfanger hændelser.
I hele eksistensen af vores mikrotjenester har der kun været en eller to hændelser, der har nået vores linje. Nu er der ingen problemer med driften. Vi har selvfølgelig ikke 200, men omkring 50 mikrotjenester, men de bruges i flagskibsprodukter. Hvis de mislykkedes, ville vi være de første til at vide om det.
Microservices og HR
Sergey:
Jeg er enig med min kollega om overflytningen til støtte - at arbejdet skal tilrettelægges korrekt. Men jeg vil fortælle dig om de problemer, der selvfølgelig er.
For det første er teknologien ny. Dette er hype på den gode måde, og det er en stor udfordring at finde en specialist, der forstår og kan skabe dette. Konkurrencen om ressourcer er vanvittig, så eksperter er guld værd.
For det andet, med skabelsen af visse landskaber og et voksende antal tjenester, skal problemet med genbrug konstant løses. Som udviklere kan lide at gøre: "Lad os skrive en masse interessante ting her nu ..." På grund af dette vokser systemet og mister sin effektivitet i form af penge, ejerskabsomkostninger og så videre. Det vil sige, at det er nødvendigt at inddrage genbrug i systemarkitekturen, inkludere det i køreplanen for at introducere tjenester og overføre arv til en ny arkitektur.
Et andet problem - selvom det er godt på sin egen måde - er den interne konkurrence. "Åh, nye moderigtige fyre er dukket op her, de taler et nyt sprog." Mennesker er selvfølgelig forskellige. Der er dem, der er vant til at skrive i Java, og dem, der skriver og bruger Docker og Kubernetes. Det er helt forskellige mennesker, de taler forskelligt, bruger forskellige udtryk og forstår nogle gange ikke hinanden. Evnen eller manglende evne til at dele praksis, videndeling, i denne forstand er også et problem.
Nå, skalering af ressourcer. "Fint, lad os gå! Og nu vil vi have hurtigere, mere. Hvad, kan du ikke? Er det ikke muligt at levere dobbelt så meget på et år? Og hvorfor?" Sådanne vokseværk er sikkert standard for mange ting, mange tilgange, og du kan mærke dem.
Angående overvågning. Det forekommer mig, at tjenester eller industrielle overvågningsværktøjer allerede lærer eller er i stand til at arbejde med både Docker og Kubernetes i en anden, ikke-standard tilstand. For at du for eksempel ikke ender med 500 Java-maskiner, hvorunder alt dette kører, nemlig det aggregeres. Men disse produkter mangler stadig modenhed, de skal igennem dette. Emnet er virkelig nyt, det vil fortsætte med at udvikle sig.
Dmitrij:
Ja, meget interessant. Og det gælder HR. Måske har din HR-proces og HR-brand ændret sig lidt i løbet af disse 3 år. Du begyndte at rekruttere andre mennesker med andre kompetencer. Og der er sikkert både fordele og ulemper. Tidligere var blockchain og datavidenskab hypen, og specialister i dem var millioner værd. Nu falder omkostningerne, markedet er ved at blive mættet, og der er en lignende tendens inden for mikrotjenester.
Sergey:
Ja absolut.
Alexander:
HR stiller spørgsmålet: "Hvor er din lyserøde enhjørning mellem backend og frontend?" HR forstår ikke, hvad en mikroservice er. Vi fortalte dem hemmeligheden og fortalte dem, at backend gjorde alt, og der er ingen enhjørning. Men HR ændrer sig, lærer hurtigt og rekrutterer folk, der har grundlæggende it-viden.
Udviklingen af mikrotjenester
Dmitrij:
Hvis du ser på målarkitekturen, ligner mikrotjenester sådan et monster. Din rejse tog flere år. Andre har et år, andre tre år. Forudså du alle problemerne, målarkitekturen, ændrede noget sig? For eksempel, når det drejer sig om mikrotjenester, dukker gateways og servicemasker nu op igen. Brugte du dem i starten, eller ændrede du selve arkitekturen? Har du sådanne udfordringer?
Sergey:
Vi har allerede omskrevet flere kommunikationsprotokoller. Først var der én protokol, nu skiftede vi til en anden. Vi øger sikkerheden og pålideligheden. Vi startede med virksomhedsteknologier - Oracle, Web Logic. Nu bevæger vi os væk fra teknologiske virksomhedsprodukter inden for mikrotjenester og går over til open source eller helt åbne teknologier. Vi opgiver databaser og flytter til det, der fungerer mere effektivt for os i denne model. Vi har ikke længere brug for Oracle-teknologier.
Vi startede simpelthen som en service, uden at tænke på hvor meget vi havde brug for en cache, hvad vi ville gøre når der ikke var forbindelse til en mikroservice, men der skulle data osv. Nu er vi ved at udvikle en platform så arkitekturen kan beskrives ikke på tjenesternes sprog, og på forretningssprog, tag forretningslogikken til det næste niveau, når vi begynder at tale i ord. Nu har vi lært at tale med bogstaver, og næste niveau er, hvornår ydelserne bliver samlet i en form for aggregat, når dette allerede er et ord - for eksempel et helt produktkort. Det er samlet fra mikrotjenester, men det er en API bygget oven på dette.
Sikkerhed er meget vigtig. Så snart du begynder at være tilgængelig, og du har en service, hvorigennem du kan få en masse interessante ting, og meget hurtigt, på et splitsekund, så er der et ønske om at få det på en ikke den mest sikre måde. For at komme væk fra dette var vi nødt til at ændre tilgang til test og overvågning. Vi skulle ændre teamet, leveringsstyringsstrukturen, CI/CD.
Dette er en udvikling - ligesom med telefoner, kun meget hurtigere: Først var der trykknaptelefoner, så dukkede smartphones op. De omskrev og redesignede produktet, fordi markedet havde et andet behov. Sådan udvikler vi os: første klasse, tiende klasse, arbejde.
Iterativt udlægges noget om året ud fra et teknologisk synspunkt, noget andet ud fra efterslæbet og behov. Vi forbinder en ting med en anden. Teamet bruger 20% på teknisk gæld og teknisk support til teamet, 80% på forretningsenheden. Og vi bevæger os med en forståelse af, hvorfor vi gør det, hvorfor vi laver disse teknologiske forbedringer, hvad de vil føre til. Sådan.
Dmitrij:
Fedt nok. Hvad er der i MegaFon?
Alexander:
Den største udfordring, da vi kom til mikrotjenester, var ikke at falde i kaos. Arkitektkontoret i MegaFon sluttede sig straks til os, blev endda initiativtager og driver - nu har vi en meget stærk arkitektur. Hans opgave var at forstå, hvilken målmodel vi skal til, og hvilke teknologier der skal piloteres. Med arkitektur gennemførte vi selv disse piloter.
Det næste spørgsmål var: "Hvordan udnytter man så alt dette?" Og en mere: "Hvordan sikrer man gennemsigtig interaktion mellem mikrotjenester?" Servicenet hjalp os med at besvare det sidste spørgsmål. Vi piloterede Istio og kunne lide resultaterne. Nu er vi ved at rulle ud i produktive zoner. Vi har en positiv indstilling til alle udfordringer - det faktum, at vi hele tiden skal skifte stakken, lære noget nyt. Vi er interesserede i at udvikle, ikke at udnytte gamle løsninger.
Dmitrij:
Guldord! Sådanne udfordringer holder teamet og forretningen på tæerne og skaber fremtiden. GDPR skabte databeskyttelseschefer, og de nuværende udfordringer skaber chefmikrotjenester og arkitekturansvarlige. Og det glæder.
Vi diskuterede meget. Det vigtigste er, at et godt design af mikrotjenester og selve arkitekturen giver dig mulighed for at undgå mange fejl. Selvfølgelig er processen iterativ og evolutionær, men det er fremtiden.
Tak til alle deltagere, tak til Sergei og Alexander!
Spørgsmål fra publikum
Spørgsmål fra salen (1):
Sergey, hvordan har it-ledelsen ændret sig i din virksomhed? Jeg forstår, at når der er en stor stak af flere systemer, er det en ret klar og logisk proces, hvordan det styres. Hvordan genopbyggede du styringen af IT-komponenten, efter at et meget stort antal mikrotjenester blev integreret på så kort tid?
Sergey:
Jeg er enig med min kollega i, at arkitektur er meget vigtig som en drivkraft for forandring. Vi startede med at have en arkitektonisk opdeling. Arkitekter er samtidig ejere af fordelingen af funktionalitet og kravene til, hvordan den vil fremstå i landskabet. Så de fungerer også som koordinatorer af disse ændringer. Som et resultat var der specifikke ændringer i en specifik leveringsproces, da vi oprettede en CI/CD-platform.
Men standarden, grundlæggende principper for udvikling, forretningsanalyse, test og udvikling er ikke blevet annulleret. Vi har lige tilføjet hastighed. Tidligere tog cyklussen så meget, installation på testmiljøer tog så meget mere. Nu ser erhvervslivet fordelen og siger: "Hvorfor kan vi ikke gøre det samme andre steder?"
Det er ligesom på en god måde en indsprøjtning i form af en vaccine, der viste: du kan gøre det på denne måde, men du kan gøre det på en anden måde. Selvfølgelig er der et problem i personale, i kompetencer, i viden, i modstand.
Spørgsmål fra salen (2):
Kritikere af mikroservicearkitektur siger, at test og udvikling er vanskeligt. Det er logisk, hvor tingene bliver komplicerede. Hvilke udfordringer stod dit team over for, og hvordan overvandt du dem? Spørgsmål til alle.
Alexander:
Der er vanskeligheder ved at flytte fra mikrotjenester til en platform, men de kan løses.
For eksempel laver vi et produkt, der består af 5-7 mikrotjenester. Vi er nødt til at levere integrationstests på tværs af hele mikroservicestakken for at give grønt lys til at flytte til masterfilialen. Denne opgave var ikke ny for os: Det havde vi gjort i lang tid hos BSS, da leverandøren forsynede os med allerede afsendte løsninger.
Og vores problem er kun i det lille hold. Der kræves én QA-ingeniør til ét betinget produkt. Og så sender vi et produkt på 5-7 mikrotjenester, hvoraf 2-3 kan udvikles af tredjeparter. For eksempel har vi et produkt under udvikling, som vores faktureringssystemleverandør, Mail.ru Group og MegaFon R&D deltager. Vi skal dække dette med test, før vi sender det til produktion. QA-ingeniøren har arbejdet på dette produkt i halvanden måned, og resten af teamet står uden hans støtte.
Denne kompleksitet er kun forårsaget af skalering. Vi forstår, at mikrotjenester ikke kan eksistere i et vakuum; absolut isolation eksisterer ikke. Når vi ændrer en tjeneste, forsøger vi altid at bevare API-kontrakten. Hvis noget ændrer sig under motorhjelmen, forbliver frontservicen. Hvis ændringerne er fatale, sker der en eller anden form for arkitektonisk transformation, og vi går over til en helt anden data-metamodel, som er fuldstændig inkompatibel – først derefter taler vi om, at v2 service API-specifikationen dukker op. Vi understøtter den første og anden version samtidigt, og efter at alle forbrugere skifter til den anden version, lukker vi blot den første.
Sergey:
Jeg vil tilføje. Jeg er helt enig med hensyn til komplikationer - de sker. Landskabet bliver mere komplekst, og de faste omkostninger er stigende, især til test. Sådan håndteres dette: Skift til automatiseret test. Ja, du bliver nødt til at investere yderligere i at skrive autotests og enhedstests. Så at udviklere ikke kunne forpligte sig uden at bestå testen, kunne de ikke ændre koden. Så selv trykknappen ikke virker uden autotest, enhedstest.
Det er vigtigt at bevare den tidligere funktionalitet, og det er ekstra overhead. Hvis du omskriver en teknologi til en anden protokol, så omskriver du den, indtil du lukker alt helt.
Vi laver nogle gange ikke ende-til-ende-test med vilje, fordi vi ikke vil stoppe udviklingen, selvom vi også har det ene efter det andet. Landskabet er meget stort, komplekst, der er mange systemer. Nogle gange er det bare stumper - ja, du sænker sikkerhedsmarginen, flere risici dukker op. Men samtidig slipper du forsyningen.
Alexander:
Ja, autotest og enhedstest giver dig mulighed for at skabe en service af høj kvalitet. Vi er for en pipeline, der ikke kan beståes uden enheds- og integrationstest. Vi er ofte nødt til at trække emulatorer og kommercielle systemer ind i testzoner og udviklingsmiljøer, fordi ikke alle systemer kan placeres i testzoner. Desuden bliver de ikke bare våde - vi genererer et fuldgyldigt svar fra systemet. Det er en seriøs del af arbejdet med mikrotjenester, og vi investerer også i det. Uden dette vil der opstå kaos.
Spørgsmål fra salen (3):
Så vidt jeg forstår, voksede mikrotjenester oprindeligt fra et separat team og eksisterer nu i denne model. Hvad er dens fordele og ulemper?
Vi har bare en lignende historie: en slags mikroservicefabrik opstod. Nu er vi konceptuelt kommet til det punkt, at vi udvider denne tilgang til produktion af strømme og systemer. Vi bevæger os med andre ord væk fra den centraliserede udvikling af mikroservices, mikroservicemodeller og kommer tættere på systemer.
Derfor går vores drift også til systemer, det vil sige, at vi decentraliserer dette emne. Hvad er din tilgang, og hvad er din målhistorie?
Alexander:
Du tabte navnet "microservices factory" lige ud af munden - vi vil også skalere. For det første har vi virkelig et hold nu. Vi ønsker at give alle udviklingsteams, som MegaFon har, mulighed for at arbejde i et fælles økosystem. Vi ønsker ikke helt at overtage al den udviklingsfunktionalitet, vi har nu. Den lokale opgave er at skalere, den globale opgave er at lede udvikling til alle teams i mikroservicelaget.
Sergey:
Jeg vil fortælle dig den vej, vi har taget. Vi begyndte virkelig at arbejde som ét team, men nu er vi ikke alene. Jeg er tilhænger af følgende: Der skal være en ejer af processen. Nogen har brug for at forstå, administrere, kontrollere og opbygge udviklingsprocessen for mikrotjenester. Han skal eje ressourcer og engagere sig i ressourceforvaltning.
Disse ressourcer, som kender teknologier, specifikationer og forstår, hvordan man bygger mikrotjenester, kan placeres i produktteams. Vi har en blanding, hvor folk fra mikroserviceplatformen er i produktteamet, der laver mobilapplikationen. De er der, men de arbejder efter processen i afdelingen for administration af mikroserviceplatforme med deres udviklingschef. Inden for denne division er der et separat team, der beskæftiger sig med teknologi. Det vil sige, at vi blander en fælles pulje af ressourcer indbyrdes og deler dem op og giver dem til teams.
Samtidig forbliver processen generel, kontrolleret, den forløber efter generelle teknologiske principper, med enhedstest og så videre - alt hvad der er bygget ovenpå. Der kan være kolonner i form af ressourcer indsamlet fra forskellige afdelinger af produkttilgangen.
Alexander:
Sergey, du er faktisk ejeren af processen, ikke? Er opgaveefterslæbet delt? Hvem er ansvarlig for distributionen?
Sergey:
Se: her er blandingen igen. Der er et efterslæb, der er dannet baseret på teknologiske forbedringer - det er én historie. Der er et efterslæb, som er formuleret ud fra projekter, og der er et efterslæb fra produkter. Men rækkefølgen af introduktion i hvert af serviceprodukterne eller oprettelsen af denne service er udviklet af en produktspecialist. Han er ikke i IT-direktoratet, han blev specielt fjernet fra det. Men mine folk arbejder bestemt efter den samme proces.
Ejeren af efterslæbet i forskellige retninger - efterslæbet af ændringer - vil være forskellige mennesker. Forbindelsen af teknologiske tjenester, deres organiseringsprincip - alt dette vil være i IT. Jeg ejer også platformen og ressourcerne. Øverst er det, der vedrører efterslæbet og funktionelle ændringer, og arkitekturen i denne forstand.
Lad os sige, at en virksomhed siger: "Vi vil have denne funktion, vi vil skabe et nyt produkt - genskabe et lån." Vi svarer: "Ja, vi vil lave det om." Arkitekter siger: "Lad os tænke: hvor i lånet vil vi skrive mikrotjenester, og hvordan vil vi gøre det?" Så opdeler vi det i projekter, produkter eller en teknologistak, sætter det i teams og implementerer det. Har du oprettet et produkt internt og besluttet at bruge mikrotjenester i dette produkt? Vi siger: "Nu skal de gamle systemer, som vi havde, eller frontlinjesystemer, skifte til disse mikrotjenester." Arkitekterne siger: "Så: i det teknologiske efterslæb inden for frontlinjeprodukterne - overgangen til mikrotjenester. Gå". Og produktspecialister eller virksomhedsejere forstår, hvor meget kapacitet der er tildelt, hvornår det vil blive gjort og hvorfor.
Slutningen af diskussionen, men ikke alle
Mailto:CLOUD-konferencen blev arrangeret .
Vi laver også andre arrangementer - f.eks. @Kubernetes Meetup, hvor vi altid leder efter gode foredragsholdere:
- Følg @Kubernetes og andre @Meetup-nyheder i vores Telegram-kanal
- Interesseret i at tale ved et af @Meetups? Efterlad en anmodning om
Kilde: www.habr.com