Mikrotjenester — en kombination af versionseksplosion

Hej, Habr! Jeg præsenterer for dig en autoriseret oversættelse af artiklen Mikrotjenester – Kombinatorisk Eksplosion af Versioner.

I en tid, hvor IT-verdenen gradvist overgår til mikrotjenester og værktøjer som Kubernetes, bliver et problem mere og mere synligt. Dette problem er kombinatorisk eksplosion af versioner af mikrotjenester. IT-fællesskabet mener dog, at den nuværende situation er betydeligt bedre end »Dependency hell« fra den tidligere generation af teknologier. Ikke desto mindre er versioneringsstyring af mikrotjenester et meget komplekst problem. Et eksempel på dette kan ses i artikler som »Giv mig min monolit tilbage«.

Hvis du, mens du læser denne tekst, ikke forstår problemet, lad mig forklare det. Antag, at dit produkt består af 10 mikrotjenester. Lad os nu antage, at der for hver af disse mikrotjenester udgives 1 ny version. Kun 1 version — jeg håber, vi alle kan blive enige om, at dette er et ganske trivielt og ubetydeligt faktum. Men lad os se en gang til på vores produkt. Med kun én ny version af hver komponent, har vi nu 2^10 — eller 1024 permutationer af, hvordan vi kan sammensætte vores produkt.

Hvis der stadig er nogen forvirring, lad mig bryde matematikken ned. Så vi har 10 mikrotjenester, hver får en opdatering. Det vil sige, at vi får 2 mulige versioner for hver mikrotjeneste (enten den gamle eller den nye). Nu har vi for hver af produktkomponenterne mulighed for at bruge en af disse to versioner. Matematikmæssigt er det det samme som at have et binært tal med 10 cifre. For eksempel, lad os sige, at 1 er den nye version, og 0 er den gamle version — så kan en mulig permutation repræsenteres som 1001000000 — hvor 1. og 4. komponent er opdateret, mens alle de andre ikke er. Fra matematikkens perspektiv ved vi, at et binært tal med 10 cifre kan have 2^10 eller 1024 værdier. Det vil sige, at vi har bekræftet omfanget af det tal, vi har med at gøre.

Lad os fortsætte med overvejelserne — hvad sker der, hvis vi har 100 mikrotjenester og hver har 10 mulige versioner? Hele situationen bliver meget ubehagelig — nu har vi 10^100 permutationer — og det er et kæmpestort tal. Ikke desto mindre foretrækker jeg at omtale denne situation på denne måde, fordi nu skjuler vi os ikke bag ord som »kubernetes«, men konfronterer problemet som det er.

Hvorfor fascinerer dette problem mig så meget? Dels fordi vi tidligere i verden af NLP og AI diskuterede problemet med den kombinatoriske eksplosion for 5-6 år siden. I stedet for versioner havde vi separate ord, og i stedet for produkter havde vi sætninger og afsnit. Selvom problemerne inden for NLP og AI i høj grad stadig står uafklaret, må det erkendes, at der er gjort betydelige fremskridt de seneste år. (efter min mening kunne fremskridtene være større,fleste afhvis folk i branchen havde givet lidt mindre opmærksomhed til maskinlæring og lidt mere til andre teknikker — men det er et off-topic emne).

Lad os vende tilbage til verdenen af DevOps og mikroservices. Vi står over for et stort problem, der gemmer sig som en elefant i et ammunitionslager — for hvad jeg ofte hører er: "bare tag Kubernetes og Helm, så bliver alt godt!" Men nej, alt bliver ikke godt, hvis man lader det stå, som det er. Desuden synes det analytiske svar på dette problem ikke acceptable givet kompleksiteten. Ligesom med NLP skal vi først nærme os dette problem ved at indsnævre søgeområdet — i dette tilfælde ved at udelukke forældede permutationer.

En af de ting, der kan hjælpe — jeg skrev i sidste år om behovet for at opretholde et minimalt spred mellem versioner, der uploades til kunderne.Det er også vigtigt at bemærke, at en veludviklet CI/CD-proces meget hjælper med at reducere variationer. Dog er den nuværende tilstand for CI/CD ikke tilstrækkelig god til at løse problemet med permutationer uden yderligere værktøjer til at holde styr på og følge komponenter.

Hvad vi har brug for, er et eksperimenteringssystem på integrationsstadiet, hvor vi kunne fastslå risikofaktoren for hver komponent og også have en automatiseret proces til opdatering af forskellige komponenter og test uden operatørens indblanding — for at se, hvad der fungerer, og hvad der ikke gør.

Et sådant eksperimenteringssystem kunne se således ud:

1. Udviklerne skriver tests (dette er et kritisk trin — for ellers har vi ikke kriteriet for evaluering — det svarer til datamærkning i maskinlæring).
2. Hver komponent (projekt) får sit eget CI-system — denne proces er i dag veludviklet, og spørgsmålet om at skabe et CI-system for en enkelt komponent er derfor stort set løst.
3. «Smart integration system» samler resultater fra forskellige CI-systemer og kompilere projektkomponenter til det endelige produkt, udfører test og beregner til sidst den korteste vej til at opnå den ønskede funktionalitet i produktet baseret på eksisterende komponenter og risikofaktorer. Hvis en opdatering ikke er muligt, informerer dette system udviklerne om de tilgængelige komponenter, og hvor fejl opstår. Jeg vil igen understrege, at testsystemet her er af kritisk betydning — da integrationssystemet bruger tests som vurderingskriterium.
4. CD-systemet, som derefter modtager data fra «Smart integration system» og udfører opdateringen. Denne fase afslutter cyklussen.

Sammenfattende er en af mine største udfordringer lige nu manglen på et sådant «Smart integration system», der kan forbinde forskellige komponenter i produktet og derved muliggøre sporing af, hvordan produktet generelt er sammensat. Jeg ville være interesseret i samfundets tanker om dette (spoiler — jeg arbejder i øjeblikket på et projekt Reliza, der kan blive et sådant smarte integrationssystem).

En sidste ting, jeg vil nævne, er, at for mig er monolitter ikke acceptable for ethvert projekt af mellem størrelse. Jeg er meget skeptisk over for forsøg på at forkorte tiden til levering og kvaliteten af udviklingen ved at vende tilbage til monolitten. For det første har monolitten et lignende problem med komponentadministration — blandt de forskellige biblioteker, den består af, men dette er ikke så synligt og viser sig primært i den tid, udviklerne bruger. Følgen af monolithproblemet er den praktiske umulighed af at foretage ændringer i koden — og en ekstremt langsom udviklingshastighed.

Mikrotjenester forbedrer situationen, men derefter står mikroservicearkitekturen over for problemet med kombinatorisk eksplosion i integrationsfasen. Ja, generelt har vi flyttet det samme problem — fra udviklingsfasen til integrationsfasen. Men efter min mening fører mikroservice-tilgangen stadig til bedre resultater, og teams når resultater hurtigere (sandsynligvis primært på grund af reducering af størrelsen på udviklingsenheden — eller batch size). Men overgangen fra monolit til mikrotjenester har endnu ikke givet en tilstrækkelig forbedring af processen — den kombinatoriske eksplosion af versioner af mikrotjenester er et enormt problem, og vi har et stort forbedringspotentiale, efterhånden som vi løser dette.

Kilde: habr.com