Hej, Habr! Jag presenterar för din uppmärksamhet författarens översättning av artikeln .
I en tid då IT-världen gradvis går mot mikrotjänster och verktyg som Kubernetes är det bara ett problem som blir mer och mer märkbart. Det här problemet - mikroserviceversioner. Ändå anser IT-gemenskapen att den nuvarande situationen är mycket bättre än tidigare generationens teknologier. Dock är versionshantering av mikrotjänster ett mycket komplext problem. Ett bevis på detta kan vara artiklar som .
Om du fortfarande inte förstår problemet genom att läsa den här texten, låt mig förklara. Låt oss säga att din produkt består av 10 mikrotjänster. Låt oss nu anta att 1 ny version släpps för var och en av dessa mikrotjänster. Endast 1 version - jag hoppas att vi alla kan vara överens om att detta är ett mycket trivialt och obetydligt faktum. Nu ska vi dock ta en ny titt på vår produkt. Med bara en ny version av varje komponent har vi nu 2^10 - eller 1024 permutationer av hur vår produkt kan vara sammansatt.
Om det fortfarande finns något missförstånd, låt mig bryta ner matematiken. Så vi har 10 mikrotjänster som var och en får en uppdatering. Det vill säga att vi får 2 möjliga versioner för varje mikrotjänst (antingen gammal eller ny). Nu, för var och en av produktkomponenterna, kan vi använda någon av dessa två versioner. Matematiskt är det samma sak som om vi hade ett binärt tal på 10 siffror. Låt oss till exempel säga att 1 är den nya versionen och 0 är den gamla versionen - då kan en möjlig permutation betecknas som 1001000000 - där den 1:a och 4:e komponenten uppdateras, och alla andra inte är det. Från matematiken vet vi att ett 10-siffrigt binärt tal kan ha 2^10 eller 1024 värden. Det vill säga, vi har bekräftat skalan på antalet vi har att göra med.
Låt oss fortsätta vårt resonemang ytterligare - vad händer om vi har 100 mikrotjänster och var och en har 10 möjliga versioner? Hela situationen blir ganska obehaglig - vi har nu 10^100 permutationer - vilket är ett enormt antal. Jag föredrar dock att beteckna den här situationen så här, eftersom vi nu inte längre gömmer oss bakom ord som "kubernetes", utan snarare står inför problemet som det är.
Varför är jag så fascinerad av detta problem? Dels för att vi, efter att ha arbetat i världen av NLP och AI, diskuterade problemet med kombinatorisk explosion mycket för ungefär 5-6 år sedan. Endast i stället för versioner hade vi enskilda ord, och istället för produkter hade vi meningar och stycken. Och även om problemen med NLP och AI förblir i stort sett olösta, måste det erkännas att betydande framsteg har gjorts under de senaste åren (enligt min åsikt kan framsteg görasоDet skulle vara bättre om människor i branschen ägnade lite mindre uppmärksamhet åt maskininlärning och lite mer till andra tekniker – men detta är redan off-topic).
Låt oss återvända till världen av DevOps och mikrotjänster. Vi står inför ett enormt problem, att vi maskerar oss som en elefant i Kunstkameran - för det jag ofta hör är "ta bara kubernetes och rodret, så kommer allt att bli bra!" Men nej, allt blir inte bra om allt lämnas som det är. Dessutom verkar en analytisk lösning på detta problem inte acceptabel på grund av dess komplexitet. Liksom i NLP bör vi först närma oss detta problem genom att begränsa sökomfånget – i det här fallet genom att eliminera föråldrade permutationer.
En av de saker som kan hjälpa är något jag skrev förra året . Det är också viktigt att notera att en väldesignad CI/CD-process i hög grad hjälper till att minska variationer. Men det nuvarande läget med CI/CD är inte tillräckligt bra för att lösa problemet med permutationer utan ytterligare verktyg för redovisning och spårning av komponenter.
Det vi behöver är ett system av experiment i integrationsstadiet, där vi kan bestämma riskfaktorn för varje komponent, och även ha en automatiserad process för att uppdatera olika komponenter och testa utan operatörsingripande – för att se vad som fungerar och vad som inte fungerar.
Ett sådant system av experiment skulle kunna se ut så här:
- Utvecklare skriver tester (detta är ett kritiskt skede - för annars har vi inget utvärderingskriterium - det är som att märka data i maskininlärning).
- Varje komponent (projekt) får sitt eget CI-system - denna process är nu väl utvecklad, och frågan om att skapa ett CI-system för en enskild komponent har till stor del lösts
- Det ”smarta integrationssystemet” samlar in resultaten av olika CI-system och sätter ihop komponentprojekt till slutprodukten, kör tester och beräknar slutligen den kortaste vägen för att erhålla önskad produktfunktionalitet baserat på befintliga komponenter och riskfaktorer. Om en uppdatering inte är möjlig meddelar detta system utvecklarna om de befintliga komponenterna och vilka av dem som orsakar felet. Återigen är testsystemet av avgörande betydelse här - eftersom integrationssystemet använder test som utvärderingskriterium.
- CD-system, som sedan tar emot data från Smart Integration System och utför uppdateringen direkt. Detta steg avslutar cykeln.
För att sammanfatta, för mig är ett av de största problemen nu avsaknaden av ett sådant "Smart Integration System" som skulle länka de olika komponenterna till en produkt och därmed låta dig spåra hur produkten som helhet är sammansatt. Jag kommer att vara intresserad av communityns tankar om detta (spoiler - jag arbetar för närvarande med ett projekt , som kan bli ett så smart integrationssystem).
En sista sak jag vill nämna är att för mig är en monolit inte acceptabel för något projekt av ens medelstor storlek. För mig orsakar försök att påskynda implementeringstiden och kvaliteten på utvecklingen genom att återgå till en monolit stor skepsis. För det första har en monolit ett liknande problem med att hantera komponenter - bland de olika biblioteken som den består av är dock allt detta inte så märkbart och manifesterar sig främst i den tid utvecklarna spenderar. Konsekvensen av monolitproblemet är den praktiska omöjligheten att göra ändringar i koden – och extremt långsam utvecklingshastighet.
Mikrotjänster förbättrar situationen, men då står mikrotjänstarkitekturen inför problemet med kombinatorisk explosion i integrationsstadiet. Ja, generellt sett har vi flyttat samma problem från utvecklingsstadiet till integrationsstadiet. Men enligt min åsikt leder mikroservicemetoden fortfarande till bättre resultat, och team uppnår resultat snabbare (förmodligen främst på grund av minskningen av storleken på utvecklingsenheten - eller satsstorlek). Men att flytta från monolit till mikrotjänster har ännu inte förbättrat processen tillräckligt - den kombinatoriska explosionen av mikrotjänstversioner är ett stort problem, och vi har mycket potential att förbättra situationen när vi löser den.
Källa: will.com