Cloud Computing Without Containers (cloudflare.com)

 ( m.informatikus | 2018. november 11., vasárnap - 10:48 )

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

erdekesen hangzik. Lehet, hogy tul gyorsan futottam at a blogon, de nem derult ki, mi a technologiai hattere...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Tologatja az ipar ide oda a terhelést a szerver és kliens oldal között. Amikor régebben lassú volt a kliens rész, akkor szerverre tolták át. Most a kliens oldalon is jelentősen növekvő kapacitás kihasználására vissza tolják (ugye kliens oldalon a kliensek száma összeadódik, ha az egész szolgáltatás terhelését nézzük). Folyamatosan találják fel a kereket.

amit irsz, az jogos optimalizacio...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Igen, csak a cikkre írtam.

Oooh, a fejlődés! A végén eljutunk a real módban futó, egy processzes operációs rendszerig...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ha belegondolunk, az egész konténerizációra azért van szükség, mert néhány dolgot nem sikerült jól megoldani. Amikor kérdezem, hogy miért kell valamihez külön VM ahelyett, hogy csak telepítenénk, akkor azt kapom, hogy:

* Összeakadhat valami mással, és nem akarjuk napokig túrni, hogy mivel hogyan
* Nem lehet egyszerre fenn az x.y és a z.w verziója valaminek
* A programok ne lássák egymást
* Egyben lehessen archiválni mindent ami a programhoz tartozik

Tehát valójában mind olyan dolog, amit az oprendszernek kellene megoldani - csak az éppenséggel nem képes ezeket jól megoldani. Csakis azért van szükség VM-ekre, mert az operációs rendszerek nem nőttek fel a feladatukhoz. Egyébként csak kernel fejlesztéshez és debuggoláshoz lenne szükség rájuk.

Amit a cikk bemutat, azt értelmes menedzselt nyelvekkel is meg lehetne csinálni (Java, .NET nyelvek, stb), de sajnos megint JavaScriptre esett a választás. Miközben teljesítményről papolnak, egy olyan nyelvet használnak, amiben inherensen van egy jókora - típusos nyelvvel elkerülhető - performance penalty. És persze TypeScript-tel használják, mert a típusok fejlesztéskor is jól jönnek. LOL

Úgy látszik nem csak nekem tűnt fel.
Én (majdnem pontonsan) ugyanerre a következtetésre python irányból jutottam. Pár dologban azért kicsit eltér a véleményem.

Tehát valójában mind olyan dolog, amit az oprendszernek kellene megoldani.
Szerintem nem. A szoftverfejlesztőnek kéne megoldania, hogy az oprendszert (tágabb értelemben: a disztrot) értelmesen használja, figyeljen arra, hogy mire épít ki függőségeket és mire nem. Vagy azokra a library-kre építsen, amik rendelkezésre állnak a disztróban, vagy ha valami hiányzik, akkor csomagolja rendesen a disztrónak megfelelő formában (ha több verzió kell, próbálja meg alternatives-szel váltani ha lehet), vagy használjon valami önhordó runtime-ot, ami megoldja a szeparált függőségkezelést (igen... JVM).

A másik, hogy a szoftverfejlesztőnek nem kéne frankenstein-alkalmazásokat csinálnia, aminek a nyakán kilógnak a csavarok. A belső business logikához tartozó ütemezett háttértaszkokat ne külső cronjob-ok indítgassák. Ne kívülről kelljen N db külön processben több példányt indítani ugyanabból a service-ből. És akkor az ezekhez használt különféle kludgy, megbízhatatlan IPC megoldásokról nem is beszéltem.

egy olyan nyelvet használnak, amiben inherensen van egy jókora - típusos nyelvvel elkerülhető - performance penalty
Nem a típusossággal van szerintem baj, de a rossz nyelvválasztással amúgy jó helyen jársz. Sokkal fundamentálisabb baj a valódi threadkezelés hiánya. Amit normálisan egy JVM házon belül megcsinál, azt Python-ban mind kívülről kell emulálni (vagy ilyen fake Greenthreads, Eventlet és hasonló kétlábon járó deadlock-tanyákkal szenvedni). A node.js dettó ugyanez, egy alapvetően single-threaded nyelv, amire különféle külső hack-eket találtak ki.

Határozottan az az érzésem, hogy erre a nagy microservice/konténerezés őrületre az teremtette meg az igényt, hogy nagy projektekre elkezdtek teljesen alkalmatlan programnyelveket választani, aztán utólag eszméltek fel, hogy jaj hát ez így hordozhatatlan, skálázhatatlan, más service-el összeférhetetlen, hardenelhetetlen. Akkor csukjuk be egy dobozba, aztán "what happens is containers, stays in containers".
---
Régóta vágyok én, az androidok mezonkincsére már!

Határozottan az az érzésem, hogy erre a nagy microservice/konténerezés őrületre az teremtette meg az igényt, hogy nagy projektekre elkezdtek teljesen alkalmatlan programnyelveket választani, aztán utólag eszméltek fel, hogy jaj hát ez így hordozhatatlan, skálázhatatlan, más service-el összeférhetetlen, hardenelhetetlen. Akkor csukjuk be egy dobozba, aztán "what happens is containers, stays in containers".

lol, egy kicsit azert utananezthetnel a koncepcionak is, hogy mire jo ...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Sajnos ezzel dolgozom... mondjuk úgy, látom az árnyoldalait is a koncepciónak...
---
Régóta vágyok én, az androidok mezonkincsére már!

> Úgy látszik nem csak nekem tűnt fel.

Hát nem kizárt, hogy még a szóhasználatot is tőled loptam egy hasonló topikból :-).

A függőségkezeléssel az van, hogy abban gondolkodunk, ami van, és szinte el sem tudjuk képzelni, hogy milyel lehetne. Ha minden alkalmazás exaktul definiálná a saját dependencijeit, és meg lehetne csinálni, hogy pontosan csak azokat lássa, semmi mást, illetve azt is, hogy egy dolognak többféle verziója lehet telepítve, és mindig azt látja az alkalmazás, ami neki megfelelő, akkor simán lehetne akármi telepítve, illetve a disztrók értelme is kicsit eltolódna. Lennenek programgyűjtemények, amik között teljes átjárhatóság lenne, hogy ki mit hova tesz fel. Ha belegondolsz, csak a kernelszolgáltatások felé nyitott interfész kellene, hogy valóban olyan függőség legyen, ami nélkül nem futhat egy program. De ezeket az interfészeket is lehetne szimulálni, illetve ezekből is lehetne több verzió egyszerre például az újon megvalósítva a régit úgy, hogy az már nem a kernel része.

(Ehhez hasonlót valósítanak meg például az OSGI konténerek Java programoknak. Persze az sem tökéletes, de legalább mutatja, hogy nem teljesen lehetetlen ilyet csinálni.)

Csak fel ne ébredjek, mert bilibe lóg a kezem.

nem kizárt, hogy még a szóhasználatot is tőled loptam egy hasonló topikból
LOL! Kösz! :)

illetve a disztrók értelme is kicsit eltolódna.
Igen, a disztrók egykor pont abból az alapvetésből indultak ki, hogy minél inkább közös függőségeket használjanak, mert... nos mert 1993-et írtunk és akkor a 120MB-os HDD nagy szám volt. Mármint az árcéduláján volt nagy szám. :) Meg azok a kis négyszögletes műanyag izék, amikről a szoftvert telepíteni kellett... olyan mint az SD kártya, csak sokkal nagyobb, lassabb, kevesebb adat fért rá, viszont milyen menő hangja volt, amikor a gépbe raktad! És piszok sok kellett belőle. :)

Aztán persze kialakult egy csomó kényelem, pl sebezhetőségnél egy központi helyen tudod, hogy kell-e frissíteni, és egy helyen frissítesz.

A függőségkezeléssel az van, hogy abban gondolkodunk, ami van, és szinte el sem tudjuk képzelni, hogy milyen lehetne.
Igen, ezzel egyetértek. Tényleg nem tudjuk hirtelen felmérni sem, hogy milyen sokmindenben építünk erre a koncepcióra és mennyi problémát kell újra megoldanunk, ha hirtelen ki találjuk dobni. Persze itt szigorúan csak a disztró csomagok függőségkezelésére gondolok. Nyilván az általad felvázolt rendszerben is az alkalmazás függőségeit valahol kezelni kell - vagyis nem maga a függőségkezelés szűnik meg, csak más szintre kerül - vagy a rendszerszinten közös függőségek helyett alkalmazásonkénti függőség modellre vált át. (Mondjuk van némi rálátásom. Melóhelyen a build-ben nálunk kell kezelni pip csomagokat, npm csomagokat, jar függőségeket, és yum repót. Ja, meg majd elfelejtettem mindezt docker image-ekben is. Nem kevés meló ment bele a license checker, a vulnerability management, és az export control report megoldásába. Ilyenkor látszik, hogy mekkora terhet vesznek le a disztró-karbantartók, mikor egy egységes interfészre konszolidálják az egészet.)

Egyébként a docker is sort-of azt csinálja amit mondasz, a maga - talán nem feltétlen optimális - módján. Ha kellő fegyelmet tartanak az image-készítők (megfelelő csomagolás a konténeren belül is, FHS betartása, hardening követelményekre ügyelés - vagyis ugyanolyan módon fejlesztenek mintha a disztóra natívan csomagból települő alkalmazást csinálnának), akkor meg lehet tartani a disztó függőségkezelés előnyeit ÉS átváltani az alkalmazás-specifikus, nem megosztott függőségekre. Tkp a docker ebből a szempontból tisztább, mint alternatives, virtualenv és hasonló hackelés. Sőt, megfelelően tervezett(!) image layer-ezéssel akár szelektív függőség-megosztás is megoldható lehet.

Na ez az a bizonyos pont, ahol ki kell venni a biliből a kezet. Mert a dockert valójában 10 esetből 9-szer nem így használják. A docker sokkal inkább "varázsszőnyeg" szerepben jelenik meg. Tudod, ami alá a szemetet be lehet söpörni. :(
---
Régóta vágyok én, az androidok mezonkincsére már!

+1 mindkettőtöknek.