Pozdravljeni, Habr! Predstavljam vašo pozornost avtorski prevod članka .
V času, ko se svet IT postopoma premika proti mikrostoritvam in orodjem, kot je Kubernetes, postaja vse bolj opazna le ena težava. Ta težava - različice mikroservisov. Kljub temu skupnost IT meni, da je trenutno stanje veliko boljše od prejšnje generacije tehnologij. Vendar je mikrostoritev z različicami zelo zapleten problem. Eden od dokazov za to so lahko članki, kot je .
Če ob branju tega besedila še vedno ne razumete problema, naj pojasnim. Recimo, da je vaš izdelek sestavljen iz 10 mikrostoritev. Zdaj pa predpostavimo, da je za vsako od teh mikrostoritev izdana 1 nova različica. Samo 1 različica - upam, da se vsi strinjamo, da je to zelo trivialno in nepomembno dejstvo. Zdaj pa si še enkrat poglejmo naš izdelek. S samo eno novo različico vsake komponente imamo zdaj 2^10 - ali 1024 permutacij, kako je lahko sestavljen naš izdelek.
Če je še vedno kakšen nesporazum, naj razčlenim matematiko. Tako imamo 10 mikrostoritev, od katerih vsaka prejme eno posodobitev. To pomeni, da dobimo 2 možni različici za vsako mikrostoritev (staro ali novo). Zdaj lahko za vsako komponento izdelka uporabimo eno od teh dveh različic. Matematično je to enako, kot če bi imeli 10-mestno binarno število. Na primer, recimo, da je 1 nova različica, 0 pa stara različica - potem je ena možna permutacija lahko označena kot 1001000000 - kjer sta 1. in 4. komponenta posodobljeni, vse druge pa ne. Iz matematike vemo, da ima lahko 10-mestno binarno število 2^10 ali 1024 vrednosti. Se pravi, potrdili smo obseg števila, s katerim imamo opravka.
Nadaljujmo naše razmišljanje naprej – kaj se bo zgodilo, če imamo 100 mikroservisov in vsaka ima 10 možnih različic? Celotna situacija postane precej neprijetna - zdaj imamo 10^100 permutacij - kar je ogromno število. Vendar to situacijo raje označim tako, ker se zdaj ne skrivamo več za besedami, kot je »kubernetes«, ampak se soočamo s problemom takšen, kot je.
Zakaj me ta problem tako fascinira? Deloma zato, ker smo prej delali v svetu NLP in umetne inteligence in smo pred približno 5-6 leti veliko razpravljali o problemu kombinatorične eksplozije. Le namesto različic smo imeli posamezne besede, namesto izdelkov pa stavke in odstavke. In čeprav težave NLP in AI ostajajo večinoma nerešene, je treba priznati, da je bil v zadnjih nekaj letih dosežen pomemben napredek (po mojem bi se dalo napredovatiоBolje bi bilo, če bi ljudje v industriji posvečali malo manj pozornosti strojnemu učenju in malo več drugim tehnikam - ampak to je že izven teme).
Vrnimo se v svet DevOps in mikrostoritev. Soočamo se z velikim problemom, maskirati se v slona v Kunstkameri - ker pogosto slišim "samo vzemite kubernete in krmilo, pa bo vse v redu!" Ampak ne, ne bo vse v redu, če ostane vse tako, kot je. Poleg tega se analitična rešitev tega problema zaradi svoje kompleksnosti ne zdi sprejemljiva. Tako kot v NLP-ju bi morali k temu problemu najprej pristopiti tako, da zožimo obseg iskanja – v tem primeru z odpravo zastarelih permutacij.
Ena od stvari, ki bi lahko pomagale, je nekaj, kar sem napisal lani . Pomembno je tudi omeniti, da dobro zasnovan proces CI/CD zelo pomaga pri zmanjševanju variacij. Vendar pa trenutno stanje s CI/CD ni dovolj dobro za rešitev problema permutacij brez dodatnih orodij za računovodstvo in sledenje komponent.
Kar potrebujemo, je sistem eksperimentiranja na stopnji integracije, kjer lahko določimo dejavnik tveganja za vsako komponento, poleg tega pa imamo avtomatiziran proces za posodabljanje različnih komponent in testiranje brez posredovanja operaterja – da vidimo, kaj deluje in kaj ne.
Takšen sistem poskusov bi lahko izgledal takole:
- Razvijalci pišejo teste (to je kritična faza - ker sicer nimamo merila za vrednotenje - to je kot označevanje podatkov pri strojnem učenju).
- Vsaka komponenta (projekt) dobi svoj sistem CI - ta proces je zdaj dobro razvit in vprašanje ustvarjanja sistema CI za posamezno komponento je v veliki meri rešeno
- »Pametni integracijski sistem« zbira rezultate različnih CI sistemov in sestavlja projekte komponent v končni izdelek, izvaja testiranje in na koncu na podlagi obstoječih komponent in dejavnikov tveganja izračuna najkrajšo pot do želene funkcionalnosti izdelka. Če posodobitev ni mogoča, ta sistem obvesti razvijalce o obstoječih komponentah in o tem, katera od njih povzroča napako. Tudi tu je testni sistem ključnega pomena, saj integracijski sistem uporablja teste kot kriterij ocenjevanja.
- CD sistem, ki nato prejme podatke iz Smart Integration System in neposredno izvede posodobitev. Ta stopnja konča cikel.
Če povzamem, je zame trenutno eden največjih problemov pomanjkanje takšnega »Smart Integration System«, ki bi povezal različne komponente v izdelek in vam tako omogočil sledenje, kako je izdelek sestavljen kot celota. Zanimalo me bo mnenje skupnosti o tem (spojler – trenutno delam na projektu , ki lahko postane tako pameten integracijski sistem).
Še zadnja stvar, ki bi jo rad omenil, je, da zame monolit ni sprejemljiv za noben projekt niti srednje velikosti. Poskusi, da bi z vrnitvijo k monolitu pospešili čas izvedbe in kakovost razvoja, zame povzročajo velik skepticizem. Prvič, monolit ima podobno težavo pri upravljanju komponent - med različnimi knjižnicami, iz katerih je sestavljen, pa vse to ni tako opazno in se kaže predvsem v času, ki ga porabijo razvijalci. Posledica problema monolita je navidezna nezmožnost spreminjanja kode - in izjemno nizka hitrost razvoja.
Mikrostoritve izboljšajo situacijo, potem pa se arhitektura mikrostoritev sooči s problemom kombinatorične eksplozije na stopnji integracije. Da, na splošno smo isti problem premaknili iz razvojne stopnje v integracijsko stopnjo. Vendar po mojem mnenju mikrostoritveni pristop še vedno vodi do boljših rezultatov, ekipe pa hitreje dosegajo rezultate (verjetno predvsem zaradi zmanjšanja velikosti razvojne enote – oz. velikost serije). Vendar prehod od monolita k mikrostoritvam še ni dovolj izboljšal procesa – kombinatorna eksplozija različic mikrostoritev je velika težava in imamo veliko možnosti, da situacijo izboljšamo, ko jo rešimo.
Vir: www.habr.com