Szia Habr! figyelmébe ajánlom a cikk szerzői fordítása .
Abban az időben, amikor az IT-világ fokozatosan a mikroszolgáltatások és az olyan eszközök felé halad, mint a Kubernetes, egyetlen probléma válik egyre szembetűnőbbé. Ez a probléma - mikroszolgáltatásos verziók. Ennek ellenére az informatikai közösség úgy véli, hogy a jelenlegi helyzet sokkal jobb, mint technológia korábbi generációja. A mikroszolgáltatások verziószáma azonban nagyon összetett probléma. Ennek egyik bizonyítéka az olyan cikkek, mint .
Ha még mindig nem érti a problémát a szöveg elolvasása után, hadd magyarázzam el. Tegyük fel, hogy a terméke 10 mikroszolgáltatásból áll. Most tegyük fel, hogy minden egyes mikroszolgáltatáshoz 1 új verzió jelenik meg. Csak 1 verzió – remélem, mindannyian egyetértünk abban, hogy ez egy nagyon triviális és jelentéktelen tény. Most azonban vessünk egy pillantást termékünkre. Az egyes összetevők egyetlen új verziójával immár 2^10 - vagy 1024 permutáció áll rendelkezésünkre termékünk összeállításához.
Ha még mindig van félreértés, hadd bontsam ki a matematikát. Tehát 10 mikroszolgáltatásunk van, mindegyik kap egy frissítést. Vagyis minden mikroszolgáltatáshoz 2 lehetséges verziót kapunk (akár régi, akár új). Most mindegyik termékösszetevőnél e két változat bármelyikét használhatjuk. Matematikailag ugyanaz, mintha 10 számjegyű bináris számunk lenne. Tegyük fel például, hogy az 1 az új verzió, a 0 pedig a régi verzió – ekkor az egyik lehetséges permutációt 1001000000-ként jelölhetjük –, ahol az 1. és 4. komponens frissül, a többi pedig nem. A matematikából tudjuk, hogy egy 10 jegyű bináris számnak 2^10 vagy 1024 értéke lehet. Vagyis megerősítettük annak a számnak a léptékét, amellyel foglalkozunk.
Folytassuk az okoskodásunkat – mi lesz, ha 100 mikroszolgáltatásunk van, és mindegyiknek 10 lehetséges verziója van? Az egész helyzet elég kellemetlenné válik - most már 10^100 permutációnk van -, ami óriási szám. Én azonban inkább így jelölöm meg ezt a helyzetet, mert most már nem olyan szavak mögé bújunk, mint a „kubernetes”, hanem úgy nézünk szembe a problémával, ahogy van.
Miért nyűgöz le ennyire ez a probléma? Részben azért, mert miután korábban az NLP és az AI világában dolgoztunk, körülbelül 5-6 éve sokat tárgyaltunk a kombinatorikus robbanás problémájáról. Csak változatok helyett egyedi szavak, termékek helyett mondatok és bekezdések voltak. És bár az NLP és az AI problémái nagyrészt megoldatlanok, el kell ismerni, hogy jelentős előrelépés történt az elmúlt néhány évben (Véleményem szerint lehetne előrelépést elérniоJobb lenne, ha az iparban dolgozók egy kicsit kevesebb figyelmet szentelnének a gépi tanulásnak, és egy kicsit többet más technikáknak – de ez már nem téma).
Térjünk vissza a DevOps és a mikroszolgáltatások világába. Óriási problémával állunk szemben, elefántnak álcázva magunkat a Kunstkamerában – mert gyakran hallom, hogy „csak fogd a kubernetes kormányt, és minden rendben lesz!” De nem, nem lesz minden rendben, ha minden úgy marad, ahogy van. Ráadásul ennek a problémának az analitikus megoldása a bonyolultsága miatt nem tűnik elfogadhatónak. Az NLP-hez hasonlóan először is a keresési hatókör szűkítésével kell megközelítenünk ezt a problémát – ebben az esetben az elavult permutációk kiiktatásával.
Az egyik dolog, ami segíthet, az, amit tavaly írtam . Azt is fontos megjegyezni, hogy egy jól megtervezett CI/CD folyamat nagyban segít a variációk csökkentésében. A CI/CD jelenlegi állapota azonban nem elég jó ahhoz, hogy a permutációk problémáját megoldja a könyvelési és nyomkövetési összetevők további eszközei nélkül.
Szükségünk van egy kísérletezési rendszerre az integráció szakaszában, ahol meg tudjuk határozni az egyes komponensek kockázati tényezőit, valamint egy automatizált folyamatot biztosítunk a különféle komponensek frissítéséhez és teszteléséhez, kezelői beavatkozás nélkül - hogy megnézzük, mi működik és mi nem.
Egy ilyen kísérleti rendszer így nézhet ki:
- A fejlesztők teszteket írnak (ez egy kritikus szakasz - mert különben nincs értékelési kritériumunk - ez olyan, mint az adatok címkézése a gépi tanulásban).
- Minden komponens (projekt) megkapja a saját CI-rendszerét - ez a folyamat mára jól fejlett, és az egyetlen komponenshez tartozó CI-rendszer létrehozásának kérdése nagyrészt megoldódott.
- Az „intelligens integrációs rendszer” összegyűjti a különböző CI-rendszerek eredményeit, és összeállítja a komponensprojekteket a végtermékké, lefuttatja a tesztelést, és végül a meglévő komponensek és kockázati tényezők alapján kiszámítja a kívánt termékfunkcionalitás eléréséhez vezető legrövidebb utat. Ha a frissítés nem lehetséges, ez a rendszer értesíti a fejlesztőket a meglévő összetevőkről és arról, hogy melyik okozza a hibát. A tesztrendszer itt is kritikus jelentőségű - hiszen az integrációs rendszer teszteket használ értékelési kritériumként.
- CD rendszer, amely azután adatokat fogad a Smart Integration System-től, és közvetlenül elvégzi a frissítést. Ez a szakasz lezárja a ciklust.
Összefoglalva, számomra az egyik legnagyobb probléma jelenleg egy ilyen „Intelligens integrációs rendszer” hiánya, amely összekapcsolná a különböző összetevőket egy termékben, és így nyomon követhető lenne a termék egészének összeállítása. Kíváncsi leszek a közösség ezzel kapcsolatos gondolataira (spoiler – jelenleg egy projekten dolgozom , amely ilyen okos integrációs rendszerré válhat).
Egy utolsó dolog, amit szeretnék megemlíteni, hogy számomra a monolit még közepes méretű projekteknél sem elfogadható. Számomra nagy szkepticizmust okoznak azok a kísérletek, amelyek a megvalósítási idő és a fejlesztés minőségének felgyorsítására irányulnak a monolithoz való visszatéréssel. Először is, a monolitnak hasonló problémája van az összetevők kezelésével - a különféle könyvtárak között, amelyekből áll, azonban mindez nem annyira észrevehető, és elsősorban a fejlesztők által eltöltött időben nyilvánul meg. A monolit probléma következménye a kód változtatásának virtuális lehetetlensége - és a rendkívül lassú fejlesztési sebesség.
A mikroszolgáltatások javítanak a helyzeten, de ekkor a mikroszolgáltatási architektúra az integrációs szakaszban szembesül a kombinatorikus robbanás problémájával. Igen, általánosságban elmondható, hogy ugyanazt a problémát a fejlesztési szakaszból az integrációs szakaszba helyeztük át. A mikroszolgáltatásos szemlélet azonban véleményem szerint még mindig jobb eredményekhez vezet, a csapatok gyorsabban érnek el eredményt (valószínűleg elsősorban a fejlesztői egység méretének csökkenése miatt - ill. csomó méret). A monolitról a mikroszolgáltatásokra való átállás azonban még nem javította kellőképpen a folyamatot - a mikroszolgáltatási verziók kombinatorikus robbanása óriási probléma, és rengeteg lehetőségünk van a helyzet javítására, ahogy megoldjuk.
Forrás: will.com