Den 25 april höll vi på Mail.ru Group en konferens om moln och runt - . Några höjdpunkter:
- Den huvudsakliga — Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, Rostelecom Data Center och Yandex.Cloud talade om detaljerna för vår molnmarknad och deras tjänster;
- Kollegor från Bitrix24 berättade hur de ;
- Leroy Merlin, Otkritie, Burger King och Schneider Electric stod för intressanta — vilka uppgifter deras verksamhet har för IT och vilka tekniker, inklusive moln, ser de som de mest lovande.
Du kan se alla videor från mailto:CLOUD-konferensen , och här kan du läsa hur diskussionen om mikrotjänster gick. Alexander Deulin, chef för MegaFons forsknings- och utvecklingscenter för affärssystem, och Sergey Sergeev, informationsteknologichef för M.Video-Eldorado-gruppen, delade med sig av sina framgångsrika fall av att bli av med monoliter. Vi diskuterade också relaterade frågor om IT-strategi, processer och även HR.
Paneldeltagare
- Sergey Sergeev, Group CIO "M.Video-Eldorado";
- Alexander Deulin, chef för centrum för forskning och utveckling av affärssystem MegaFon;
- Moderator - Dmitrij Lazarenko, Chef för PaaS-riktningen Mail.ru molnlösningar.
Efter Alexander Deulins tal han har sällskap för diskussion av Sergey Sergeev från M.Video-Eldorado och diskussionsmoderator Dmitry Lazarenko, Mail.ru Cloud Solutions.
Nedan har vi förberett en utskrift av diskussionen åt dig, men du kan också se videon:
Övergången till mikrotjänster är ett svar på marknadens behov
Dmitriy:
Har du haft någon framgångsrik erfarenhet av att migrera till mikrotjänster? Och generellt: var ser du den största affärsnyttan av att använda mikrotjänster eller att gå från monoliter till mikrotjänster?
Sergey:
Vi har redan kommit en bit på vägen i övergången till mikrotjänster och har använt detta tillvägagångssätt i mer än tre år. Det första behovet som motiverade behovet av mikrotjänster var den oändliga integrationen av olika front-end-produkter med backoffice. Och varje gång vi tvingades göra ytterligare integration och utveckling, implementera våra egna regler för driften av den här eller den tjänsten.
Vid något tillfälle insåg vi att vi behövde påskynda driften av våra system och produktionen av funktionalitet. I det ögonblicket fanns redan koncept som mikrotjänster och en mikrotjänstmetod på marknaden, och vi bestämde oss för att prova det. Detta började 2016. Sedan lades plattformen och de första 10 tjänsterna implementerades av ett separat team.
En av de första tjänsterna, den mest belastade, var priskalkyltjänsten. Varje gång du kommer till någon kanal, till M.Video-Eldorado-gruppen av företag, oavsett om det är en webbplats eller en butik, välj en produkt där, se priset på webbplatsen eller i "Korgen", kostnaden automatiskt beräknas av en tjänst. Varför är detta nödvändigt: innan detta hade varje system sina egna principer för att arbeta med kampanjer - med rabatter och så vidare. Vårt backoffice hanterar prissättning, rabattfunktionalitet implementeras i ett annat system. Detta behövde centraliseras och en unik, separerbar tjänst skapas i form av en affärsprocess som skulle göra det möjligt för oss att implementera detta. Det var ungefär så vi började.
Värdet av de första resultaten var mycket stort. För det första kunde vi skapa separerbara enheter som gör att vi kan arbeta separat och på ett aggregerat sätt. För det andra har vi minskat ägandekostnaderna när det gäller integration med fler system.
Under de senaste tre åren har vi lagt till tre frontlinjesystem. Det var svårt att underhålla dem med samma mängd resurser som företaget hade råd med. Därför uppstod uppgiften att leta efter nya försäljningsställen, svara på marknaden när det gäller hastighet, i termer av interna kostnader och effektivitet.
Hur man mäter framgången med att migrera till mikrotjänster
Dmitriy:
Hur avgörs framgången med att migrera till mikrotjänster? Vad var "förut" i varje företag? Vilket mått använde du för att avgöra om övergången lyckades, och vem avgjorde egentligen den?
Sergey:
Först och främst föddes det inom IT som en möjliggörare - "låsa upp" nya möjligheter. Vi hade ett behov av att göra allt snabbare för relativt samma pengar och svara på marknadens utmaningar. Nu uttrycks framgången i antalet tjänster som återanvänds av olika system, förening av processer sinsemellan. Nu är det så, men i det ögonblicket var det en möjlighet att skapa en plattform och bekräfta hypotesen att vi kan göra detta, det kommer att ge effekt och beräkna affärscase.
Alexander:
Framgång är snarare en intern känsla. Företagen vill alltid ha mer, och djupet i vår eftersläpning är ett bevis på framgång. Det verkar så för mig.
Sergey:
Ja jag håller med. På tre år har vi redan mer än tvåhundra tjänster och eftersläpning. Behovet av resurser inom teamet bara växer – med 30 % årligen. Det här händer för att folk kände: det är snabbare, det är annorlunda, det finns olika teknologier, allt detta utvecklas.
Mikrotjänster kommer, men kärnan kommer att finnas kvar
Dmitriy:
Det är som en oändlig process där man investerar i utveckling. Är övergången till mikrotjänster för företag redan över eller inte?
Sergey:
Det är väldigt lätt att svara på. Vad tycker du: att byta ut telefoner är en oändlig process? Själva köper vi telefoner varje år. Och här är det: så länge det finns ett behov av snabbhet, för anpassning till marknaden, kommer det att krävas vissa förändringar. Det betyder inte att vi överger standardsaker.
Men vi kan inte täcka och göra om allt på en gång. Vi har äldre, standardintegrationstjänster som fanns tidigare: företagsbussar och så vidare. Men det finns en eftersläpning, och det finns också ett behov. Antalet mobila applikationer och deras funktionalitet växer. Samtidigt är det ingen som säger att du kommer att få 30 % mer pengar. Det vill säga, det finns alltid behov å ena sidan, och ett sökande efter effektivitet å andra sidan.
Dmitriy:
Livet är i bra form. (Skrattar)
Alexander:
I allmänhet, ja. Vi har inga revolutionerande tillvägagångssätt för att ta bort kärndelen från landskapet. Ett systematiskt arbete pågår för att bryta ner system så att de blir mer överensstämmande med mikrotjänstarkitektur, för att minska systemens inflytande på varandra.
Men vi planerar att behålla kärndelen, eftersom det i operatörens landskap alltid kommer att finnas några plattformar som vi köper. Återigen, vi behöver en sund balans: vi bör inte skynda oss att skära ut kärnan. Vi placerar systemen sida vid sida, och nu visar det sig att vi redan ligger ovanpå många kärndelar. Genom att vidareutveckla funktionaliteten skapar vi nödvändiga representationer för alla kanaler som arbetar med våra kommunikationstjänster.
Hur man säljer mikrotjänster till företag
Dmitriy:
Jag är också intresserad - för dem som inte har bytt, men planerar att: hur lätt var det att sälja den här idén till företag och var det ett äventyr, ett investeringsprojekt? Eller var det en medveten strategi: nu går vi till mikrotjänster och det är det, ingenting kommer att stoppa oss. Hur var det för dig?
Sergey:
Vi sålde inte ett tillvägagångssätt, utan en affärsnytta. Det fanns ett problem i affären och vi försökte lösa det. I det ögonblicket tog det sig uttryck i att olika kanaler använde olika principer för att beräkna priser - separat för kampanjer, för kampanjer och så vidare. Det var svårt att underhålla, fel uppstod och vi lyssnade på kundklagomål. Det vill säga vi sålde en lösning på ett problem, men vi kom med det faktum att vi behövde pengar för att skapa en plattform. Och de visade ett affärscase med exemplet med det första investeringsskedet: hur vi kommer att fortsätta att få tillbaka det och vad detta kommer att tillåta oss att göra.
Dmitriy:
Spelade du på något sätt tiden för den första etappen?
Sergey:
Ja visst. Vi avsatte 6 månader för att skapa kärnan som plattform och testa piloten. Under den här tiden försökte vi skapa en plattform för att åka skridskor piloten. Sedan bekräftades hypotesen, och eftersom den fungerar betyder det att vi kan fortsätta. De började replikera och stärkte laget - de flyttade det till en separat division som gör just det.
Därefter kommer ett systematiskt arbete utifrån affärsbehov, möjligheter, tillgång på resurser och allt som just nu är på gång.
Dmitriy:
OK. Alexander, vad säger du?
Alexander:
Våra mikrotjänster föddes ur "havets skum" - på grund av att spara resurser, på grund av en del överbliven kapacitet i form av serverkapacitet och omfördelning av krafter inom teamet. Till en början sålde vi inte detta projekt till företag. Det här var ett projekt där vi både forskade och utvecklade oss därefter. Vi började i början av 2018 och utvecklade helt enkelt denna riktning med entusiasm. Försäljningen har precis börjat och vi är i processen.
Dmitriy:
Händer det att ett företag låter dig göra sådana saker som Google – på en ledig dag i veckan? Har du en sådan riktning?
Alexander:
Samtidigt som forskningen sysslade vi också med affärsproblem, så alla våra mikrotjänster är lösningar på affärsproblem. Bara i början byggde vi mikrotjänster som täckte en liten del av abonnentbasen, och nu finns vi i nästan alla flaggskeppsprodukter.
Och den materiella påverkan är redan klar – vi kan redan räknas, hastigheten på produktlanseringar och förlorade intäkter kan uppskattas om vi hade följt den gamla vägen. Det är detta vi bygger ärendet på.
Mikrotjänster: hype eller nödvändighet?
Dmitriy:
Siffror är siffror. Och intäkter eller sparade pengar är mycket viktigt. Tänk om du tittar på andra sidan? Det verkar som att mikrotjänster är en trend, en hype och många företag missbrukar det? Hur tydligt skiljer du på vad du gör och inte översätter till mikrotjänster? Om arv nu, kommer du fortfarande att ha arv om 5 år? Hur gammal är informationssystemen som fungerar på M.Video-Eldorado och MegaFon om 5 år? Kommer det att finnas tio år, femton år gamla informationssystem eller blir det en ny generation? Hur ser du på detta?
Sergey:
Det verkar för mig som att det är svårt att tänka väldigt långt bort. Om vi ser tillbaka, vem trodde att teknikmarknaden skulle utvecklas på detta sätt, inklusive maskininlärning och användaridentifiering genom ansikte? Men om man tittar på de kommande åren verkar det för mig som om kärnsystem, affärssystem i ERP-klass i företag - de har fungerat ganska länge.
Våra företag är tillsammans 25 år gamla, med klassisk affärssystem väldigt djupt inne i systemlandskapet. Det är klart att vi tar några bitar därifrån och försöker samla dem till mikrotjänster, men kärnan kommer att finnas kvar. Det är svårt för mig nu att föreställa mig att vi kommer att ersätta alla kärnsystem där och snabbt gå över till den andra ljusa sidan av de nya systemen.
Jag är en anhängare av att allt som är närmare kunden och konsumenten är där den största affärsnyttan och värdet finns, där anpassningsförmåga och fokus på snabbhet, på förändring, på "prova, avbryt, återanvänd, gör något annorlunda" är behövs ”—det är där landskapet kommer att förändras. Och förpackade produkter passar inte in där särskilt bra. Vi ser det åtminstone inte. Där krävs de enklaste och enklaste lösningarna.
Vi ser denna utveckling:
- kärninformationssystem (främst backoffice);
- mellanlager i form av mikrotjänster kopplar samman kärnan, aggregerar, skapar en cache och så vidare;
- frontlinjesystem riktar sig till konsumenten;
- ett integrationsskikt som generellt är integrerat i marknadsplatser, andra system och ekosystem. Detta lager är så lätt som möjligt, enkelt och innehåller ett minimum av affärslogik.
Men jag är samtidigt en anhängare av att fortsätta använda de gamla principerna om de används på rätt sätt.
Låt oss säga att du har ett klassiskt företagssystem. Den ligger i en leverantörs landskap och består av två moduler som fungerar med varandra. Det finns också ett standardintegrationsgränssnitt. Varför göra om det och ta med en mikrotjänst dit?
Men när det finns 5 moduler i backoffice, från vilka delar av information samlas in i en affärsprocess, som sedan används av 8-10 frontlinjesystem, märks fördelen direkt. Du tar från fem back-office-system och skapar en tjänst, en isolerad, som är fokuserad på affärsprocessen. Gör tjänsten tekniskt avancerad – så att den cachar information och är feltålig, och även fungerar med dokument eller affärsenheter. Och du integrerar det enligt en enda princip med alla frontlinjeprodukter. De avbröt frontlinjeprodukten – de stängde helt enkelt av integrationen. I morgon behöver du skriva en mobilapplikation eller göra en liten webbplats och bara lägga en del i funktionalitet - allt är enkelt: du har satt ihop det som en konstruktör. Jag ser mer utveckling åt det hållet – åtminstone i vårt land.
Alexander:
Sergey beskrev helt vårt tillvägagångssätt, tack. Jag ska bara säga vart vi definitivt inte kommer att gå - till kärndelen, till ämnet onlinefakturering. Det vill säga att betyg och laddning förblir i själva verket en "stor" tröska som på ett tillförlitligt sätt kommer att skriva av pengar. Och detta system kommer även fortsättningsvis att vara certifierat av våra tillsynsmyndigheter. Allt annat som vänder sig till kunderna är naturligtvis mikrotjänster.
Dmitriy:
Här är certifiering en historia. Förmodligen mer stöd. Om du spenderar lite på support eller om systemet inte kräver support och modifiering är det bättre att inte röra det. En rimlig kompromiss.
Hur man utvecklar pålitliga mikrotjänster
Dmitriy:
Bra. Men jag är fortfarande intresserad. Nu berättar du en framgångssaga: allt var bra, vi bytte till mikrotjänster, försvarade idén för verksamheten och allt fungerade. Men jag har hört andra historier.
För ett par år sedan avslutade ett schweiziskt företag som hade investerat två år i att utveckla en ny mikrotjänstplattform för banker projektet. Helt kollapsade. Många miljoner schweiziska franc spenderades, och till slut skingrades laget - det fungerade inte.
Har du haft liknande historier? Fanns eller finns det några svårigheter? Till exempel är underhåll av mikrotjänster och övervakning också en huvudvärk i företagets operativa verksamhet. När allt kommer omkring ökar antalet komponenter tiotals gånger. Hur ser du på det, har det varit misslyckade exempel på investeringar här? Och vad kan du råda folk så att de inte stöter på sådana problem?
Alexander:
Misslyckade exempel var företag som ändrade prioriteringar och avbröt projekt. När i ett bra stadium av beredskap (i själva verket är MVP redo), sa verksamheten: "Vi har nya prioriteringar, vi går vidare till ett annat projekt och vi stänger detta."
Vi hade inga globala fel med mikrotjänster. Vi sover lugnt, vi har ett vaktpass dygnet runt som servar hela BSS [företagsstödsystemet].
Och en sak till – vi hyr ut mikrotjänster enligt de regler som gäller för förpackade produkter. Nyckeln till framgång är att du för det första behöver sätta ihop ett team som helt förbereder mikrotjänsten för produktion. Själva utvecklingen är villkorligt 40%. Resten är analys, DevSecOps-metodik, rätt integrationer och rätt arkitektur. Vi lägger särskild vikt vid principerna för att bygga säkra applikationer. Informationssäkerhetsrepresentanter deltar i varje projekt både i arkitekturplaneringsstadiet och under implementeringsprocessen. De hanterar också system för att analysera kod för sårbarheter.
Låt oss säga att vi distribuerar våra statslösa tjänster – vi har dem i Kubernetes. Detta gör att alla kan sova lugnt på grund av automatisk skalning och automatisk höjning av tjänster, och vaktskiftet tar upp incidenter.
Under hela existensen av våra mikrotjänster har det bara varit en eller två incidenter som har nått vår linje. Nu är det inga problem med driften. Vi har naturligtvis inte 200 utan cirka 50 mikrotjänster, men de används i flaggskeppsprodukter. Om de misslyckades skulle vi vara de första att veta om det.
Microservices och HR
Sergey:
Jag håller med min kollega om övergången till stöd – att arbetet behöver organiseras rätt. Men jag ska berätta om de problem som naturligtvis finns.
För det första är tekniken ny. Det här är hype på ett bra sätt, och att hitta en specialist som förstår och kan skapa detta är en stor utmaning. Konkurrensen om resurser är galen, så experter är guld värda.
För det andra, med skapandet av vissa landskap och ett växande antal tjänster måste problemet med återanvändning ständigt lösas. Som utvecklare gillar att göra: "Låt oss skriva en massa intressanta saker här nu..." På grund av detta växer systemet och förlorar sin effektivitet i form av pengar, ägandekostnader och så vidare. Det vill säga att det är nödvändigt att inkludera återanvändning i systemarkitekturen, inkludera den i färdplanen för att introducera tjänster och överföra arv till en ny arkitektur.
Ett annat problem - även om detta är bra på sitt sätt - är den interna konkurrensen. "Åh, nya fashionabla killar har dykt upp här, de talar ett nytt språk." Människor är naturligtvis olika. Det finns de som är vana vid att skriva i Java, och de som skriver och använder Docker och Kubernetes. Det är helt olika människor, de talar olika, använder olika termer och förstår ibland inte varandra. Förmågan eller oförmågan att dela praktik, kunskapsdelning, i denna mening är också ett problem.
Tja, skala resurser. "Bra då går vi! Och nu vill vi ha snabbare, mer. Vadå, kan du inte? Går det inte att leverera dubbelt så mycket på ett år? Och varför?" Sådana växtvärk är förmodligen standard för många saker, många tillvägagångssätt, och du kan känna dem.
Angående övervakning. Det verkar för mig som att tjänster eller industriella övervakningsverktyg redan lär sig eller kan arbeta med både Docker och Kubernetes i ett annat, icke-standardläge. Så att du till exempel inte hamnar med 500 Java-maskiner som allt detta körs under, nämligen att det samlas. Men dessa produkter saknar fortfarande mognad, de måste gå igenom detta. Ämnet är verkligen nytt, det kommer att fortsätta utvecklas.
Dmitriy:
Ja, mycket intressant. Och det gäller HR. Kanske har din HR-process och HR-varumärke förändrats lite under dessa 3 år. Du började rekrytera andra människor med olika kompetenser. Och det finns nog både för- och nackdelar. Tidigare var blockchain och datavetenskap hypen, och specialister på dem var värda miljoner. Nu sjunker kostnaden, marknaden blir mättad och det finns en liknande trend inom mikrotjänster.
Sergey:
Ja absolut.
Alexander:
HR ställer frågan: "Var är din rosa enhörning mellan backend och frontend?" HR förstår inte vad en mikrotjänst är. Vi berättade hemligheten för dem och berättade för dem att backend gjorde allt, och det finns ingen enhörning. Men HR förändras, lär sig snabbt och rekryterar personer som har grundläggande IT-kunskaper.
Utvecklingen av mikrotjänster
Dmitriy:
Om du tittar på målarkitekturen ser mikrotjänster ut som ett sådant monster. Din resa tog flera år. Andra har ett år, andra tre år. Förutsåg du alla problem, målarkitekturen, förändrades något? Till exempel, när det gäller mikrotjänster, dyker nu gateways och servicenät upp igen. Använde du dem i början eller ändrade du själva arkitekturen? Har du sådana utmaningar?
Sergey:
Vi har redan skrivit om flera kommunikationsprotokoll. Först fanns det ett protokoll, nu bytte vi till ett annat. Vi ökar säkerheten och tillförlitligheten. Vi började med företagsteknologier - Oracle, Web Logic. Nu går vi bort från tekniska företagsprodukter inom mikrotjänster och går över till öppen källkod eller helt öppen teknik. Vi överger databaser och går över till det som fungerar mer effektivt för oss i den här modellen. Vi behöver inte längre Oracle-teknik.
Vi började helt enkelt som en tjänst, utan att tänka på hur mycket vi behövde en cache, vad vi skulle göra när det inte fanns någon koppling till en mikrotjänst, utan data behövdes etc. Nu utvecklar vi en plattform så att arkitekturen kan beskrivas inte på tjänstespråket, och på affärsspråk, ta affärslogik till nästa nivå när vi börjar prata i ord. Nu har vi lärt oss att tala i bokstäver, och nästa nivå är när tjänsterna ska samlas till något slags aggregat, när detta redan är ett ord – till exempel ett helt produktkort. Det är sammansatt från mikrotjänster, men det är ett API byggt ovanpå detta.
Säkerheten är mycket viktig. Så fort du börjar vara tillgänglig och du har en tjänst genom vilken du kan få en massa intressanta saker, och väldigt snabbt, på en bråkdel av en sekund, så finns det en önskan att få det på ett inte det säkraste sättet. För att komma ifrån detta var vi tvungna att ändra metoder för testning och övervakning. Vi var tvungna att ändra teamet, leveranshanteringsstrukturen, CI/CD.
Det här är en utveckling - precis som med telefoner, bara mycket snabbare: först fanns det tryckknappstelefoner, sedan dök det upp smartphones. De skrev om och designade om produkten eftersom marknaden hade ett annat behov. Så här utvecklas vi: första klass, tionde klass, arbete.
Iterativt läggs något per år ur teknisk synvinkel, något annat ur eftersläpnings- och behovssynpunkt. Vi kopplar en sak till en annan. Teamet spenderar 20 % på teknisk skuld och teknisk support för teamet, 80 % på affärsenheten. Och vi rör oss med en förståelse för varför vi gör det, varför vi gör dessa tekniska förbättringar, vad de kommer att leda till. Sådär.
Dmitriy:
Häftigt. Vad finns i MegaFon?
Alexander:
Den största utmaningen när vi kom till mikrotjänster var att inte hamna i kaos. Arkitektkontoret i MegaFon anslöt sig omedelbart till oss, blev till och med en initiativtagare och drivkraft - nu har vi en mycket stark arkitektur. Hans uppgift var att förstå vilken målmodell vi går till och vilka teknologier som behöver piloteras. Med arkitektur genomförde vi dessa piloter själva.
Nästa fråga var: "Hur kan man då utnyttja allt detta?" Och en till: "Hur säkerställer man transparent interaktion mellan mikrotjänster?" Servicenätet hjälpte oss att svara på den sista frågan. Vi testade Istio och gillade resultaten. Nu är vi i stadiet att rulla ut i produktiva zoner. Vi har en positiv inställning till alla utmaningar – det faktum att vi hela tiden behöver byta stacken, lära oss något nytt. Vi är intresserade av att utveckla, inte att utnyttja gamla lösningar.
Dmitriy:
Guldord! Sådana utmaningar håller teamet och verksamheten på tårna och skapar framtiden. GDPR skapade dataskyddschefer, och nuvarande utmaningar skapar chefsansvariga för mikrotjänster och arkitektur. Och det behagar.
Vi diskuterade mycket. Huvudsaken är att en bra design av mikrotjänster och själva arkitekturen gör att du kan undvika många misstag. Naturligtvis är processen iterativ och evolutionär, men det är framtiden.
Tack till alla deltagare, tack till Sergei och Alexander!
Frågor från publiken
Fråga från publiken (1):
Sergey, hur har IT-hanteringen förändrats i ditt företag? Jag förstår att när det finns en stor stack av flera system är hur det hanteras en ganska tydlig och logisk process. Hur byggde du om hanteringen av IT-komponenten efter att ett mycket stort antal mikrotjänster integrerats på så kort tid?
Sergey:
Jag håller med min kollega om att arkitektur är väldigt viktig som en drivkraft för förändring. Vi började med att ha en arkitektonisk uppdelning. Arkitekter är samtidigt ägare till fördelningen av funktionalitet och kraven på hur den ska se ut i landskapet. Så de fungerar också som samordnare av dessa förändringar. Som ett resultat av detta skedde specifika ändringar i en specifik leveransprocess när vi skapade en CI/CD-plattform.
Men standarden, grundläggande principer för utveckling, affärsanalys, testning och utveckling har inte upphävts. Vi har precis lagt till hastigheten. Tidigare tog cykeln så mycket, installation i testmiljöer tog så mycket mer. Nu ser näringslivet fördelen och säger: "Varför kan vi inte göra samma sak på andra platser?"
Det är som, på ett bra sätt, en injektion i form av ett vaccin som visade: du kan göra det på det här sättet, men du kan göra det på ett annat sätt. Naturligtvis finns det ett problem i personal, i kompetens, i kunskap, i motstånd.
Fråga från publiken (2):
Kritiker av mikrotjänstarkitektur säger att testning och utveckling är svår. Detta är logiskt när saker och ting blir komplicerade. Vilka utmaningar mötte ditt team och hur övervann du dem? Fråga till alla.
Alexander:
Det finns svårigheter när man flyttar från mikrotjänster till en plattform, men de kan lösas.
Vi gör till exempel en produkt som består av 5-7 mikrotjänster. Vi måste tillhandahålla integrationstester över hela mikroservicestacken för att ge grönt ljus för att flytta till huvudgrenen. Den här uppgiften var inte ny för oss: vi hade gjort det här länge på BSS, när leverantören försåg oss med redan levererade lösningar.
Och vårt problem är bara i det lilla laget. En QA-ingenjör behövs för en villkorad produkt. Och så skickar vi en produkt med 5-7 mikrotjänster, varav 2-3 kan utvecklas av tredje part. Till exempel har vi en produkt under utveckling där vår leverantör av faktureringssystem, Mail.ru Group och MegaFon R&D deltar. Vi måste täcka detta med tester innan vi skickar det till produktion. QA-ingenjören har arbetat med den här produkten i en och en halv månad, och resten av teamet lämnas utan hans stöd.
Denna komplexitet orsakas endast av skalning. Vi förstår att mikrotjänster inte kan existera i ett vakuum; absolut isolering existerar inte. När vi byter en tjänst försöker vi alltid behålla API-kontraktet. Om något förändras under motorhuven, finns frontservicen kvar. Om förändringarna är fatala sker någon form av arkitektonisk transformation och vi går över till en helt annan datametamodell, som är helt inkompatibel – först då pratar vi om att v2-tjänstens API-specifikation dyker upp. Vi stöder den första och andra versionen samtidigt, och efter att alla konsumenter byter till den andra versionen stänger vi helt enkelt den första.
Sergey:
Jag vill tillägga. Jag håller helt med om komplikationer - de händer. Landskapet blir mer komplext och omkostnader ökar, särskilt för testning. Hur man hanterar detta: byt till automatiserad testning. Ja, du kommer att behöva investera ytterligare i att skriva autotester och enhetstester. Så att utvecklare inte kunde begå utan att klara testet kunde de inte ändra koden. Så att även tryckknappen inte fungerar utan autotest, enhetstest.
Det är viktigt att behålla den tidigare funktionaliteten, och detta är ytterligare omkostnader. Om du skriver om en teknik till ett annat protokoll, så skriver du om det tills du stänger allt helt.
Ibland gör vi inte end-to-end-testning med flit, eftersom vi inte vill stoppa utvecklingen, även om vi också har det ena efter det andra. Landskapet är mycket stort, komplext, det finns många system. Ibland är det bara stubbar - ja, du sänker säkerhetsmarginalen, fler risker dyker upp. Men samtidigt släpper du på utbudet.
Alexander:
Ja, autotester och enhetstester låter dig skapa en tjänst av hög kvalitet. Vi är för en pipeline som inte kan klaras utan enhets- och integrationstester. Vi måste ofta dra in emulatorer och kommersiella system till testzoner och utvecklingsmiljöer, eftersom inte alla system kan placeras i testzoner. Dessutom blir de inte bara blöta - vi genererar ett fullfjädrat svar från systemet. Det här är en seriös del av arbetet med mikrotjänster och vi satsar också på det. Utan detta kommer kaos att uppstå.
Fråga från publiken (3):
Så vitt jag förstår växte mikrotjänster till en början från ett separat team och finns nu i denna modell. Vilka är dess för- och nackdelar?
Vi har bara en liknande historia: en sorts mikroservicefabrik uppstod. Nu har vi konceptuellt kommit till den punkt att vi utvidgar detta tillvägagångssätt till produktion av strömmar och system. Med andra ord, vi går bort från den centraliserade utvecklingen av mikrotjänster, mikrotjänstmodeller, och kommer närmare system.
Följaktligen går vår verksamhet också till system, det vill säga vi decentraliserar detta ämne. Vad är ditt förhållningssätt och vad är din målhistoria?
Alexander:
Du tappade namnet "microservices factory" direkt ur munnen - vi vill också skala. För det första har vi verkligen ett lag nu. Vi vill ge alla utvecklingsteam som MegaFon har möjlighet att arbeta i ett gemensamt ekosystem. Vi vill inte helt ta över all utvecklingsfunktion som vi har nu. Den lokala uppgiften är att skala, den globala uppgiften är att leda utvecklingen till alla team i mikroservicelagret.
Sergey:
Jag ska berätta vilken väg vi har tagit. Vi började verkligen arbeta som ett team, men nu är vi inte ensamma. Jag är en förespråkare för följande: det måste finnas en ägare till processen. Någon behöver förstå, hantera, kontrollera och bygga utvecklingsprocessen för mikrotjänster. Han måste äga resurser och engagera sig i resursförvaltning.
Dessa resurser, som kan teknologier, detaljer och förstår hur man bygger mikrotjänster, kan placeras i produktteam. Vi har en mix där personer från mikrotjänstplattformen finns i produktteamet som gör mobilapplikationen. De finns där, men de arbetar enligt processen för avdelningen för hantering av mikroserviceplattformar med sin utvecklingschef. Inom denna division finns ett separat team som sysslar med teknik. Det vill säga att vi blandar en gemensam pool av resurser sinsemellan och delar upp dem och ger dem till team.
Samtidigt förblir processen generell, kontrollerad, den fortskrider enligt allmänna tekniska principer, med enhetstester och så vidare - allt som är byggt ovanpå. Det kan finnas kolumner i form av resurser som samlats in från olika avdelningar av produktansatsen.
Alexander:
Sergey, du är faktiskt ägaren till processen, eller hur? Är uppgiftseftersläpningen delad? Vem ansvarar för distributionen?
Sergey:
Titta: här är blandningen igen. Det finns en eftersläpning som bildas baserat på tekniska förbättringar - det här är en historia. Det finns en eftersläpning, som är formulerad från projekt, och det finns en eftersläpning från produkter. Men sekvensen för introduktion i var och en av tjänsteprodukterna eller skapandet av denna tjänst utvecklas av en produktspecialist. Han är inte i IT-direktoratet, han togs speciellt bort från det. Men mitt folk arbetar definitivt enligt samma process.
Ägaren av eftersläpningen i olika riktningar - eftersläpningen av förändringar - kommer att vara olika människor. Anslutningen av tekniska tjänster, deras organiseringsprincip - allt detta kommer att vara i IT. Jag äger plattformen och resurserna också. Överst ligger vad som rör eftersläpningen och funktionsförändringar, och arkitekturen i denna mening.
Låt oss säga att ett företag säger: "Vi vill ha den här funktionen, vi vill skapa en ny produkt - gör om ett lån." Vi svarar: "Ja, vi gör om det." Arkitekter säger: "Låt oss tänka: var i lånet kommer vi att skriva mikrotjänster och hur ska vi göra det?" Sedan bryter vi ner det i projekt, produkter eller en teknikstack, lägger in det i team och implementerar det. Har du skapat en produkt internt och bestämt dig för att använda mikrotjänster i den här produkten? Vi säger: "Nu måste de äldre systemen som vi hade, eller frontlinjesystemen, byta till dessa mikrotjänster." Arkitekterna säger: "Så: i den tekniska eftersläpningen inom frontlinjeprodukterna - övergången till mikrotjänster. Gå". Och produktspecialister eller företagsägare förstår hur mycket kapacitet som tilldelas, när det kommer att göras och varför.
Slutet på diskussionen, men inte allt
Mailto:CLOUD-konferensen anordnades .
Vi gör även andra evenemang – t.ex. @Kubernetes Meetup, där vi alltid letar efter bra talare:
- Följ @Kubernetes och andra @Meetup-nyheter i vår Telegram-kanal
- Intresserad av att prata på ett av @Meetups? Lämna en begäran om
Källa: will.com