Kaixo, Habr! Zure arreta aurkezten dut egilearen artikuluaren itzulpena .
IT mundua pixkanaka mikrozerbitzuetara eta Kubernetes bezalako tresnetara joaten den garai honetan, arazo bakarra gero eta nabarmenagoa da. Arazo hau - mikrozerbitzuen bertsioak. Hala ere, IT komunitateak uste du egungo egoera baino askoz hobea dela aurreko teknologien belaunaldia. Hala ere, mikrozerbitzuen bertsioak oso arazo konplexua da. Horren froga bat bezalako artikuluak izan daitezke .
Testu hau irakurrita oraindik arazoa ulertzen ez baduzu, utz iezadazu azaltzen. Demagun zure produktua 10 mikrozerbitzuk osatzen dutela. Orain demagun mikrozerbitzu horietako bakoitzeko bertsio berri bat kaleratzen dela. Bertsio bakarra - denok ados egon gaitezkeela espero dut oso gertaera hutsala eta hutsala dela. Orain, ordea, eman diezaiogun beste begirada bat gure produktuari. Osagai bakoitzaren bertsio berri bakarrarekin, orain 1^1 - edo 2 permutazio ditugu gure produktua nola osatu daitekeen.
Gaizki-ulerturik badago oraindik, utz iezadazu matematika hausten. Beraz, 10 mikrozerbitzu ditugu, bakoitzak eguneratze bat jasotzen duena. Hau da, mikrozerbitzu bakoitzeko 2 bertsio posible lortzen ditugu (zaharra edo berria). Orain, produktuaren osagai bakoitzeko, bi bertsio hauetako bat erabil dezakegu. Matematikoki, 10 zifrako zenbaki bitarra izango bagenu bezala da. Esaterako, demagun 1 bertsio berria dela eta 0 bertsio zaharra dela - gero permutazio posible bat 1001000000 gisa adierazi daiteke - non 1. eta 4. osagaiak eguneratzen diren, eta beste guztiak ez. Matematikatik badakigu 10 zifrako zenbaki bitar batek 2^10 edo 1024 balio izan ditzakeela. Hau da, jorratzen ari garen kopuruaren tamaina baieztatu dugu.
Jarrai dezagun gure arrazoiketa gehiago: zer gertatuko da 100 mikrozerbitzu baditugu eta bakoitzak 10 bertsio posible baditu? Egoera osoa nahiko desatsegina bihurtzen da - orain 10^100 permutazio ditugu - kopuru handia da. Dena den, nahiago dut egoera hau horrela etiketatu, orain ez baikara gehiago ezkutatzen βkubernetesβ bezalako hitzen atzean, baizik eta arazoari dagoen bezala aurre egiten.
Zergatik liluratzen nau arazo honek? Neurri batean, lehenago NLP eta AI munduan lan egin genuenez, duela 5-6 urte inguru konbinazio-leherketaren arazoa asko eztabaidatu genuen. Bertsioen ordez bakarrik hitz indibidualak genituen, eta produktuen ordez esaldiak eta paragrafoak genituen. Eta NLP eta AIren arazoak neurri handi batean konpondu gabe jarraitzen badute ere, onartu beharra dago azken urteotan aurrerapen handiak eman direla. (Nire ustez, aurrera egin litekeΠΎHobe litzateke industriako jendeak arreta apur bat gutxiago ematea makina ikaskuntzari eta apur bat gehiago beste teknika batzuei - baina hori dagoeneko gaitik kanpo dago).
Itzuli gaitezen DevOps eta mikrozerbitzuen mundura. Arazo handi baten aurrean gaude, Kunstkameran elefante baten itxuraz mozorrotuta, askotan entzuten dudana "hartu kubernetes eta lema, eta dena ondo egongo da!" Baina ez, dena ez da ondo egongo dena dagoen bezala uzten bada. Gainera, arazo honen konponbide analitikoa ez da onargarria iruditzen bere konplexutasunagatik. NLPn bezala, lehenik eta behin arazo honi heldu beharko genioke bilaketa-esparrua murriztuz, kasu honetan, permutazio zaharkituak ezabatuz.
Lagun dezakeen gauzetako bat iaz idatzi nuen zerbait da . Garrantzitsua da ere ondo diseinatutako CI/CD prozesu batek asko laguntzen duela aldakuntzak murrizten. Hala ere, CI/CD-ren egungo egoera ez da nahikoa permutazioen arazoa konpontzeko kontabilitate- eta jarraipen-osagaietarako tresna osagarririk gabe.
Behar duguna integrazio fasean esperimentazio-sistema bat da, non osagai bakoitzaren arrisku-faktorea zehaztu ahal izateko, eta, gainera, hainbat osagai eguneratzeko eta probak egiteko prozesu automatizatu bat edukitzea operadorearen esku-hartzerik gabe, zer funtzionatzen duen eta zer ez ikusteko.
Horrelako esperimentu sistemak honelako itxura izan dezake:
- Garatzaileek probak idazten dituzte (etapa kritikoa da - bestela ez baitugu ebaluazio irizpiderik - ikaskuntza automatikoan datuak etiketatzea bezalakoa da).
- Osagai (proiektu) bakoitzak bere CI sistema jasotzen du - orain prozesu hau ondo garatuta dago, eta osagai bakarrerako CI sistema bat sortzearen arazoa neurri handi batean konpondu da.
- "Integrazio sistema adimendunak" hainbat CI sistemaren emaitzak biltzen ditu eta osagaien proiektuak azken produktuan muntatzen ditu, probak egiten ditu eta, azkenik, nahi den produktuaren funtzionaltasuna lortzeko biderik laburrena kalkulatzen du, dauden osagaietan eta arrisku-faktoreetan oinarrituta. Eguneratzea posible ez bada, sistema honek lehendik dauden osagaien berri ematen die garatzaileei eta horietako akatsa zein den eragiten duen. Berriro ere, proba-sistemak garrantzi kritikoa du hemen, integrazio-sistemak probak erabiltzen baititu ebaluazio-irizpide gisa.
- CD sistema, gero Smart Integration System-etik datuak jasotzen dituena eta eguneratzea zuzenean egiten duena. Etapa honek zikloari amaiera ematen dio.
Laburbilduz, niretzat orain arazo handienetako bat osagai desberdinak produktu batean lotuko lituzkeen "Integrazio Sistema Adimendun" baten falta da eta horrela produktua bere osotasunean nola biltzen den jarraitzeko aukera emango dizu. Komunitatearen hausnarketak interesatuko zaizkit (spoiler - proiektu batean ari naiz lanean , integrazio sistema adimenduna bihur daitekeena).
Aipatu nahi dudan azken gauza bat da, niretzat, monolito bat ez dela onargarria tamaina ertaineko edozein proiekturentzat. Niretzat, monolito batera itzuliz inplementazio denbora eta garapenaren kalitatea bizkortzeko saiakerek eszeptizismo handia eragiten dute. Lehenik eta behin, monolito batek osagaiak kudeatzeko antzeko arazoa du - osatzen duten liburutegi ezberdinen artean, hala ere, hori guztia ez da hain nabarmena eta garatzaileek emandako denboran agertzen da batez ere. Monolitoaren arazoaren ondorioa kodean aldaketak egiteko ezintasun birtuala da - eta garapen-abiadura oso motela.
Mikrozerbitzuek egoera hobetzen dute, baina gero mikrozerbitzuen arkitekturak integrazio fasean leherketa konbinatiboaren arazoari aurre egiten dio. Bai, orokorrean, arazo bera garapen fasetik integrazio fasera eraman dugu. Hala ere, nire ustez, mikrozerbitzuen ikuspegiak oraindik ere emaitza hobeak lortzen ditu, eta taldeek azkarrago lortzen dituzte emaitzak (seguruenik, batez ere, garapen-unitatearen tamaina murrizteagatik - edo lotearen tamaina). Hala ere, monolitotik mikrozerbitzuetara pasatzeak oraindik ez du prozesua nahikoa hobetu - mikrozerbitzuen bertsioen eztanda konbinatiboa arazo itzela da, eta egoera hobetzeko potentzial handia dugu hori konpontzen dugun heinean.
Iturria: www.habr.com