Përshëndetje, Habr! Unë paraqes në vëmendjen tuaj përkthimi i artikullit nga autori .
Në një kohë kur bota e IT po shkon gradualisht drejt mikroshërbimeve dhe mjeteve si Kubernetes, vetëm një problem po bëhet gjithnjë e më i dukshëm. Ky problem - versionet e mikroservisit. Megjithatë, komuniteti i IT beson se situata aktuale është shumë më e mirë se gjenerata e mëparshme e teknologjive. Megjithatë, versionimi i mikroshërbimeve është një problem shumë kompleks. Një provë për këtë mund të jenë artikuj si .
Nëse ende nuk e kuptoni problemin duke lexuar këtë tekst, më lejoni të shpjegoj. Le të themi se produkti juaj përbëhet nga 10 mikroshërbime. Tani le të supozojmë se 1 version i ri është lëshuar për secilin nga këto mikroshërbime. Vetëm 1 version - Shpresoj se të gjithë mund të pajtohemi se ky është një fakt shumë i parëndësishëm dhe i parëndësishëm. Tani, megjithatë, le t'i hedhim një vështrim tjetër produktit tonë. Me vetëm një version të ri të secilit komponent, tani kemi 2^10 - ose 1024 ndërrime se si mund të kompozohet produkti ynë.
Nëse ka akoma ndonjë keqkuptim, më lejoni të zbërthej matematikën. Pra, ne kemi 10 mikroshërbime, secili merr një përditësim. Kjo do të thotë, ne marrim 2 versione të mundshme për çdo mikroshërbim (qoftë i vjetër ose i ri). Tani, për secilin nga komponentët e produktit, ne mund të përdorim njërin nga këto dy versione. Matematikisht, është njësoj sikur të kishim një numër binar prej 10 shifrash. Për shembull, le të themi se 1 është versioni i ri, dhe 0 është versioni i vjetër - atëherë një ndërrim i mundshëm mund të shënohet si 1001000000 - ku komponentët e 1-rë dhe të 4-të janë përditësuar, dhe të gjithë të tjerët jo. Nga matematika dimë se një numër binar 10-shifror mund të ketë 2^10 ose 1024 vlera. Domethënë ne kemi konfirmuar shkallën e numrit me të cilin kemi të bëjmë.
Le të vazhdojmë arsyetimin tonë më tej - çfarë do të ndodhë nëse kemi 100 mikroshërbime dhe secili ka 10 versione të mundshme? E gjithë situata bëhet mjaft e pakëndshme - tani kemi 10^100 permutacione - që është një numër i madh. Megjithatë, unë preferoj ta etiketoj këtë situatë në këtë mënyrë, sepse tani nuk fshihemi më pas fjalëve si "kubernetes", por po përballemi me problemin ashtu siç është.
Pse jam kaq i magjepsur nga ky problem? Pjesërisht sepse, pasi kemi punuar më parë në botën e NLP dhe AI, ne diskutuam shumë problemin e shpërthimit kombinator rreth 5-6 vjet më parë. Vetëm në vend të versioneve kishim fjalë individuale dhe në vend të produkteve kishim fjali dhe paragrafë. Dhe megjithëse problemet e NLP dhe AI mbeten kryesisht të pazgjidhura, duhet pranuar se është bërë përparim i rëndësishëm gjatë viteve të fundit (për mendimin tim, mund të bëhet përparimоDo të ishte më mirë nëse njerëzit në industri do t'i kushtonin pak më pak vëmendje mësimit të makinerive dhe pak më shumë teknikave të tjera - por kjo tashmë është jashtë temës).
Le të kthehemi në botën e DevOps dhe mikroshërbimeve. Ne jemi përballur me një problem të madh, duke u maskuar si një elefant në Kunstkamera - sepse ajo që dëgjoj shpesh është "thjesht merrni kubernetet dhe timonin dhe gjithçka do të jetë mirë!" Por jo, gjithçka nuk do të jetë mirë nëse gjithçka lihet ashtu siç është. Për më tepër, një zgjidhje analitike e këtij problemi nuk duket e pranueshme për shkak të kompleksitetit të tij. Ashtu si në NLP, së pari duhet t'i qasemi këtij problemi duke ngushtuar fushën e kërkimit - në këtë rast, duke eliminuar permutacionet e vjetruara.
Një nga gjërat që mund të ndihmojë është diçka që kam shkruar vitin e kaluar . Është gjithashtu e rëndësishme të theksohet se një proces CI/CD i projektuar mirë ndihmon shumë në reduktimin e variacionit. Megjithatë, gjendja aktuale e punëve me CI/CD nuk është mjaft e mirë për të zgjidhur problemin e permutacioneve pa mjete shtesë për kontabilitetin dhe përcjelljen e komponentëve.
Ajo që na nevojitet është një sistem eksperimentimi në fazën e integrimit, ku mund të përcaktojmë faktorin e rrezikut për secilin komponent, si dhe të kemi një proces të automatizuar për përditësimin e komponentëve të ndryshëm dhe testimin pa ndërhyrjen e operatorit - për të parë se çfarë funksionon dhe çfarë jo.
Një sistem i tillë eksperimentesh mund të duket si ky:
- Zhvilluesit shkruajnë teste (kjo është një fazë kritike - sepse përndryshe nuk kemi asnjë kriter vlerësimi - është si etiketimi i të dhënave në mësimin e makinerive).
- Secili komponent (projekt) merr sistemin e tij CI - ky proces tani është zhvilluar mirë, dhe çështja e krijimit të një sistemi CI për një komponent të vetëm është zgjidhur kryesisht
- "Sistemi i integrimit inteligjent" mbledh rezultatet e sistemeve të ndryshme CI dhe grumbullon projekte përbërëse në produktin përfundimtar, kryen testimin dhe në fund llogarit rrugën më të shkurtër për të marrë funksionalitetin e produktit të dëshiruar bazuar në komponentët ekzistues dhe faktorët e rrezikut. Nëse një përditësim nuk është i mundur, ky sistem njofton zhvilluesit për komponentët ekzistues dhe se cili prej tyre po e shkakton gabimin. Edhe një herë, sistemi i testimit është i një rëndësie kritike këtu - pasi sistemi i integrimit përdor testet si kriter vlerësimi.
- Sistemi CD, i cili më pas merr të dhëna nga Smart Integration System dhe kryen përditësimin drejtpërdrejt. Kjo fazë përfundon ciklin.
Për ta përmbledhur, për mua një nga problemet më të mëdha tani është mungesa e një "Sistemi Inteligjent Integrimi" që do të lidhë komponentët e ndryshëm në një produkt dhe kështu do t'ju lejojë të gjurmoni se si produkti në tërësi është i bashkuar. Do të më interesojnë mendimet e komunitetit për këtë (spoiler - aktualisht jam duke punuar në një projekt , i cili mund të bëhet një sistem kaq i zgjuar integrimi).
Një gjë e fundit që dua të përmend është se, për mua, një monolit nuk është i pranueshëm për asnjë projekt qoftë edhe mesatar. Për mua, përpjekjet për të përshpejtuar kohën e zbatimit dhe cilësinë e zhvillimit duke u kthyer në një monolit shkaktojnë skepticizëm të madh. Së pari, një monolit ka një problem të ngjashëm të menaxhimit të komponentëve - midis bibliotekave të ndryshme nga të cilat përbëhet, megjithatë, e gjithë kjo nuk është aq e dukshme dhe manifestohet kryesisht në kohën e kaluar nga zhvilluesit. Pasoja e problemit të monolitit është pamundësia virtuale për të bërë ndryshime në kod - dhe shpejtësia jashtëzakonisht e ngadaltë e zhvillimit.
Mikroshërbimet përmirësojnë situatën, por më pas arkitektura e mikroshërbimeve përballet me problemin e shpërthimit kombinator në fazën e integrimit. Po, në përgjithësi, të njëjtin problem e kemi kaluar nga faza e zhvillimit në fazën e integrimit. Sidoqoftë, për mendimin tim, qasja e mikroshërbimeve ende çon në rezultate më të mira, dhe ekipet arrijnë rezultate më shpejt (ndoshta kryesisht për shkak të zvogëlimit të madhësisë së njësisë së zhvillimit - ose madhësia e grupit). Megjithatë, kalimi nga monoliti në mikroshërbime nuk e ka përmirësuar ende procesin mjaftueshëm - shpërthimi kombinues i versioneve të mikroshërbimeve është një problem i madh dhe ne kemi shumë potencial për të përmirësuar situatën ndërsa e zgjidhim atë.
Burimi: www.habr.com