Hei, Habr! Jeg presenterer for din oppmerksomhet forfatterens oversettelse av artikkelen .
I en tid hvor IT-verdenen gradvis beveger seg mot mikrotjenester og verktøy som Kubernetes, er det bare ett problem som blir mer og mer merkbart. Dette problemet - mikroserviceversjoner. Likevel mener IT-miljøet at dagens situasjon er mye bedre enn tidligere generasjon teknologier. Imidlertid er versjonsstyring av mikrotjenester et veldig komplekst problem. Et bevis på dette kan være artikler som .
Hvis du fortsatt ikke forstår problemet ved å lese denne teksten, la meg forklare. La oss si at produktet ditt består av 10 mikrotjenester. La oss nå anta at 1 ny versjon er utgitt for hver av disse mikrotjenestene. Kun 1 versjon - jeg håper vi alle kan være enige om at dette er et veldig trivielt og ubetydelig faktum. La oss nå ta en ny titt på produktet vårt. Med bare én ny versjon av hver komponent har vi nå 2^10 - eller 1024 permutasjoner av hvordan produktet vårt kan sammensettes.
Hvis det fortsatt er noen misforståelser, la meg bryte ned regnestykket. Så vi har 10 mikrotjenester, som hver mottar en oppdatering. Det vil si at vi får 2 mulige versjoner for hver mikrotjeneste (enten gammel eller ny). Nå, for hver av produktkomponentene, kan vi bruke en av disse to versjonene. Matematisk er det det samme som om vi hadde et binært tall på 10 sifre. La oss for eksempel si at 1 er den nye versjonen, og 0 er den gamle versjonen - da kan en mulig permutasjon betegnes som 1001000000 - der 1. og 4. komponent er oppdatert, og alle de andre ikke er det. Fra matematikken vet vi at et 10-sifret binært tall kan ha 2^10 eller 1024 verdier. Det vil si at vi har bekreftet skalaen på tallet vi har med å gjøre.
La oss fortsette resonnementet vårt videre - hva vil skje hvis vi har 100 mikrotjenester og hver har 10 mulige versjoner? Hele situasjonen blir ganske ubehagelig - vi har nå 10^100 permutasjoner - som er et enormt antall. Jeg foretrekker imidlertid å merke denne situasjonen på denne måten, for nå gjemmer vi oss ikke lenger bak ord som «kubernetes», men står overfor problemet som det er.
Hvorfor er jeg så fascinert av dette problemet? Delvis fordi vi, etter å ha jobbet i NLP- og AI-verdenen, diskuterte problemet med kombinatorisk eksplosjon mye for 5-6 år siden. Bare i stedet for versjoner hadde vi individuelle ord, og i stedet for produkter hadde vi setninger og avsnitt. Og selv om problemene med NLP og AI forblir stort sett uløste, må det innrømmes at det er gjort betydelige fremskritt de siste årene (etter min mening kan det gjøres fremskrittоDet ville vært bedre om folk i bransjen la litt mindre oppmerksomhet til maskinlæring og litt mer til andre teknikker - men dette er allerede off-topic).
La oss gå tilbake til verden av DevOps og mikrotjenester. Vi står overfor et stort problem, å forkle oss som en elefant i Kunstkameraet - for det jeg ofte hører er "bare ta kubernetes og roret, så blir alt bra!" Men nei, alt blir ikke bra hvis alt blir stående som det er. Dessuten virker en analytisk løsning på dette problemet ikke akseptabel på grunn av kompleksiteten. Som i NLP, bør vi først nærme oss dette problemet ved å begrense søkeomfanget – i dette tilfellet ved å eliminere utdaterte permutasjoner.
En av tingene som kan hjelpe er noe jeg skrev i fjor . Det er også viktig å merke seg at en godt designet CI/CD-prosess i stor grad hjelper til med å redusere variasjon. Men dagens tilstand med CI/CD er ikke god nok til å løse problemet med permutasjoner uten ekstra verktøy for regnskap og sporing av komponenter.
Det vi trenger er et system for eksperimentering på integrasjonsstadiet, hvor vi kan bestemme risikofaktoren for hver komponent, og også ha en automatisert prosess for oppdatering av ulike komponenter og testing uten operatørintervensjon – for å se hva som fungerer og ikke.
Et slikt system av eksperimenter kan se slik ut:
- Utviklere skriver tester (dette er et kritisk stadium - for ellers har vi ikke noe evalueringskriterium - det er som å merke data i maskinlæring).
- Hver komponent (prosjekt) mottar sitt eget CI-system - denne prosessen er nå godt utviklet, og problemet med å lage et CI-system for en enkelt komponent er i stor grad løst
- Det «smarte integrasjonssystemet» samler resultatene fra ulike CI-systemer og setter sammen komponentprosjekter til sluttproduktet, kjører testing og beregner til slutt den korteste veien til å oppnå ønsket produktfunksjonalitet basert på eksisterende komponenter og risikofaktorer. Hvis en oppdatering ikke er mulig, varsler dette systemet utviklerne om de eksisterende komponentene og hvilke av dem som forårsaker feilen. Nok en gang er testsystemet av avgjørende betydning her - siden integrasjonssystemet bruker tester som evalueringskriterium.
- CD-system, som deretter mottar data fra Smart Integration System og utfører oppdateringen direkte. Dette stadiet avslutter syklusen.
For å oppsummere, for meg er et av de største problemene nå mangelen på et slikt "Smart Integration System" som vil koble de forskjellige komponentene inn i et produkt og dermed tillate deg å spore hvordan produktet som helhet er satt sammen. Jeg vil være interessert i fellesskapets tanker om dette (spoiler - jeg jobber for tiden med et prosjekt , som kan bli et så smart integreringssystem).
En siste ting jeg vil nevne er at for meg er en monolitt ikke akseptabel for ethvert prosjekt av middels størrelse. For meg forårsaker forsøk på å fremskynde implementeringstiden og kvaliteten på utviklingen ved å gå tilbake til en monolitt stor skepsis. For det første har en monolitt et lignende problem med å administrere komponenter - blant de forskjellige bibliotekene den består av, er imidlertid ikke alt dette så merkbart og manifesterer seg først og fremst i tiden utviklerne bruker. Konsekvensen av monolittproblemet er den praktiske umuligheten av å gjøre endringer i koden – og ekstremt lav utviklingshastighet.
Mikrotjenester forbedrer situasjonen, men så står mikrotjenestearkitekturen overfor problemet med kombinatorisk eksplosjon på integrasjonsstadiet. Ja, generelt sett har vi flyttet det samme problemet fra utviklingsstadiet til integreringsstadiet. Etter min mening fører imidlertid mikrotjenester-tilnærmingen fortsatt til bedre resultater, og team oppnår resultater raskere (sannsynligvis hovedsakelig på grunn av reduksjonen i størrelsen på utviklingsenheten - eller Partistørrelse, Gruppestørrelse). Men å flytte fra monolitt til mikrotjenester har ennå ikke forbedret prosessen nok - den kombinatoriske eksplosjonen av mikrotjenesteversjoner er et stort problem, og vi har mye potensiale til å forbedre situasjonen etter hvert som vi løser den.
Kilde: www.habr.com
