- Samsung Galaxy S24 - nos, Exynos
- Redmi Watch 4 - olcsó hús, sűrű a leve
- iPhone topik
- Android alkalmazások - szoftver kibeszélő topik
- Ezek a OnePlus 12 és 12R európai árai
- Telekom mobilszolgáltatások
- Samsung Galaxy A70 - áram, erősség
- Apple Watch Sport - ez is csak egy okosóra
- Samsung Galaxy S21 Ultra - vákuumcsomagolás
- Garmin Forerunner 165 - alapozó edzés
Hirdetés
-
Ülésezik a hardveregylet
ph Az irodai készülékek és monitorok társaságát egy ház, egy egér és egy DAC egészíti ki.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Premier előzetesen a Demon Slayer -Kimetsu no Yaiba- Sweep the Board!
gp Elérhető lett Switch-re a játék, amely leginkább a Mario Party-hoz hasonlítható.
Új hozzászólás Aktív témák
-
mire 5 év múlva bevezetné, addigra lecseng ez a marhaság, és más buzzword lesz népszerű.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
nekem az első gondom a szemlélettel van: amikor valaki összevonja a fejlesztést meg az üzemeltetést, akkor azt hiszi, hogy lehet valaki mindkettőben egyszerre jó. ezzel valamelyik vagy mindkét szakmai ágat degradálja. szerintem mindkét szakmai ág teljes embert kíván, annyi kraft senkiben sincs, hogy mindkettőben jó legyen.
a másik probléma, hogy annak a fajta devopskodásnak, amiket látni a neten, akkor van értelme, ha vagy fizetős cloudba pakolsz, vagy cloud eszközökből saját hardveren privát cloudot építesz. a publikus cloud nálam egyértelműen a szakmai öngyilkosság kategória, a privát cloud meg csak sima tévedés.
ez az egész cloud mizéria arról szól, hogy mindig kell valami buzzword, amit gyakran hangoztatva managgák kihajthatják egymásból a pénzt. majd kiheverik ezt is, elmúlik, mint az outsource mánia. buzzwordok jönnek, managgák mennek, a karaván pedig halad. a régi megszokott módon.
a következő probléma a cloud rendszer. világos, hogy ha elkészül egy program(release), akkor azt be kell csomagolni valami telepíthető formába. Ez a forma a két világ közötti antagonisztikus ellentét alapján lehet:
- az oprendszer saját csomagkezelő rendszerének formátuma
- a konténer formátuma.ha megcsináltam mondjuk a .deb-et, egy utasítás, felrakom, jónapot.
ha konténert (pl. docker image-t) csináltam belőle, akkor kell konténer szoftver, meg annak a vezérléséhez nagy kosár más cucc is, pl. puppetet meg chef-t hallottam sokat emlegetni. azoknak a technológiáknak egy része, amit a konténerhez használsz, megvolt előtte is, pl. redundáns, storage alapú tároló volt régen is, ebből is látszik, hogy a konténer dili csak egy marketing buzzword. más részére meg egyáltalán nem lenne szükség, ha rendesen raktad volna össze az architektúrát, nem pedig cloudosan.probléma még, hogy azt mondod: felgyorsítja a fejlesztési ciklust. ezt azért több oldalról is lehetne vitatni:
1. nem a fejlesztési ciklus egészét gyorsítja fel, hanem a deployt. ettől nem fog gyorsabban programozni a kódkrampácsoló elvtárs, hogy utána gyorsabban buildelődik a cucc és hamarabb ki tudod tolni a produkcióba.
2. a fejlesztési ciklus felgyorsítása gyakorlatilag egyet jelent azzal, hogy sokkal hatékonyabban hagyod benne a hibákat. szét lehet nézni a világban, egy informatikai szemétdombon ülünk, de legalább gyorsabban cserélik a pelenkát, ha ijedtedben összef.stad magad. kiemelt példa lehet a fejlesztési ciklus felgyorsítására a trészisztem bérlet alkalmazása... azt is úgy felgyorsították, mint a huzat...
3. felszínesen belenéztem egy-két fejlesztési módszertanba, van, amelyik arra optimalizál, hogy nem tudjuk mit akar a megrendelő, de elkezdjük legyártani, és milyen szuper csávók vagyunk, hogyha kiderül, hogy nem is ezt akarta, akkor qrva gyorsan tudunk irányt váltani. ja, ezzel nagyjából ki is dobtad az addigi munkát. ennek megfelelően csodálkoznak, hogy nagyon nehéz programozót kapni a munkaerőpiacon, akit egyébként is arra használnál, hogy kidobd a munkáját.
4. a 3.-as pont következménye: a rendes folyamatszervezést szerintem nem lehet megspórolni, még akkor sem, ha mostani módszertanok ezzel kecsegtetnek.és akkor még nem beszéltünk arról, hogy magát a konténer technológiát meg a felhőt is pont ugyanolyan elrontott fejlesztési módszertannal fejlesztik, mint aminek az elrontására felhasználják azokat. vagyis bugos mind. minél több réteget húzol a bare metal meg az user közé, annál több bug lesz a komplett rendszerben. annál lassabb lesz. annál nehezebben fogod tudni megtalálni a hibát.
következmény: a cloud és a devops 90%-ban pazarlás. 10%-ban pedig egy pénzszivattyú, amivel átverik a megrendelőt. a cloud egyetlen entitás-fajtának érdeke: akinek fizetsz érte. csak és kizárólag azért erőltetik, mert másképp már nem tudják növelni a bevételt.
az, hogy ettől a témától függetlenül is úgy általában informatikai szemétdombon ülünk, szerintem bizonyítás nélkül elfogadható állítás. ma egy desktop pc-ben ugyanolyan számjegy van a memória méreténél, mint régen, csak egy ezressel nagyobb szorzó. ettől senkinek a munkája nem lett érdemben hatékonyabb. max. annyi eredményt hozott, hogy folyamatosan csökken az iq küszöb, ami a gép használatához kell. és ez tényleg olyan jó nekünk, mint rendszergarázdák?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
"A devops nem arrol szol, hogy nincs ops, hanem arrol, hogy a fejlesztes resze az, hogy aktivan gondolkozunk az uzemeltethetosegrol es az uzemeltetesrol is.": nekem ehhez nem kell devops. egyébként pedig de, a devops arról szól, hogy nem kell ops, majd a dev opsol is.*
"Pelda: a fejlesztes resze az, hogy megtervezzuk, hogy milyen health checkek lesznek, kell-e circuit breaker, milyen skalazasi problemak varhatoak. Satobbi.": mit értesz circuit breaker alatt? kismegszakítót? mert ha igen, neked fejlesztés közben be kell kalkulálnod, hogy milyen áramellátás lesz? és ha máshova telepítik, újra fogod fordítani?
egyébként pedig ne tervezd meg, hogy milyen skálázási problémák várhatók. azt tervezed meg, hogy hogyan oldod meg a skálázási problémákat.
"Az agile nem/sem helyettesiti a megfelelo folyamatszervezest, nyilvan.": a rendes folyamatszervezés megléte kizárja, hogy folyton kihajigálj kódokat, mert a megrendelő nem arra gondolt.
a kritikádból még mindig nem kaptam elég motivációt, hogy devopsozzak meg cloudoljak.
* kell valakinek aláírásba?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
"Értem, hogy ez az egész abból ered, hogy az üzlet szeretne gyorsabban, olcsóbban haladni": nem. az üzlet üzletet szeretne kötni. erről szól a történet, hogy ha nincs buzzword, nincs valami hangzatos fícsör, amit marketingelni lehet, akkor senki nem veszi meg a következő verziót. se a konténerből, se a cloudból, se semmiből.
pontosan ugyanaz a probléma az üzemeltetés környékén, mint az xp. a júzerek elsöprő többségének elég volt az xp, és lehet, még ma is elég lenne. ehhez képest keresztültapostak rajtuk egy vistát, egy w7-et, egy 8/8.1-et meg egy 10-est. ebből a pistát meg a 8.x-et simán ki lehetett volna hagyni. de akkor bizonyos cégnek meg a disztribútoraiknak nem lesz meg az év végi pulykapénz. tehát ki kell találni valamit, amitől a nagyobb vevők a zsebükbe nyúlnak. de ahogy halad az idő, úgy egyre kevesebb dolog maradt, aminek értelme/haszna is van, tehát minél nagyobb dolgot találnak ki, az annál nagyobb valószínűséggel ökörség. most nem kipécéztem az ms-t, csak szemléltettem vele. ugyanez igaz az összes cloud szolgáltatóra, meg a többi köztesszoftver árusra.
meg azt hallani, igaz, csak olyanok szájából, akik konténert fejlesztenek, hogy ha nem tudsz két perc alatt 100 ezer node-ra deployolni, akkor itt az armageddon és éhező gyerekek fognak hullani az égből. miközben ha kihagynák a szemetet a rendszerből, lehet 200 node elég lenne ugyanarra az ügyfélélményre...
mesterségesen feltekert igények ezek.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
"Kontenereket egyszerubb deployolni, mint .deb fajlokat peldaul.": .deb natívan van egy csomó oprendszerben, a konténerhez meg kell egy csomó konténer infrastruktúra. tehát ez az állítás nem igaz.
Az összehasonlításod érdekes: feltételezed, hogy vlanokat kézzel fog csinálni a rendszergazda, miközben a docker swarm az meg csak úgy ott van. a múltkor is mentem a szerverszobába, oszt dikkmá, egy docker swarm...
"Most miert lenne jo nekem, ha nem kontenerrel csinalnam?": mert akkor csak konténert, swarmot, chefet, meg ansible-t nem kell megtanulnod, telepítened, üzemeltetned, debuggolnod, frissítened, stb. ha nekem applikációt kellene frissítenem, pont elég lenne kiharcolni az app frissítési ablakát, nem akarnék még docker frissítési ablakért is kardozni.
"Ja, es ha kell egy uj V(X)LAN, akkor Swarm-mal az 2 uj sor a deployment descriptorban, nem pedig ot napos varakozas a rendszergazdara.": értem, tehát szerinted ez a két véglet létezik, hogy vagy swarmban két sor (mellesleg: a swarmnak is kell hardver konfig, ha nem úgy van összerakva), vagy pedig öt nap? és biztos nincs arany középút, ahol swarm nélkül is automatizálva van az ilyen, és működik rendesen?
szerk: ja, és a biztonság meg a konténer szavakat ne írjuk már le egy lapon belül please.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Új hozzászólás Aktív témák
ph A japán vállalat felmérése szerint alig van olyan nagyvállalat, amelyik nem tervezi a címben említett modell bevezetését.
- Übergyors Samsungnak próbál látszani egy hamisított NVMe SSD
- Samsung Galaxy S24 - nos, Exynos
- Redmi Watch 4 - olcsó hús, sűrű a leve
- iPhone topik
- Linux - haladóknak
- NASCAR
- NOTEBOOK / NETBOOK / Mac beárazás
- Gitáros topic
- OLED TV topic
- Android alkalmazások - szoftver kibeszélő topik
- További aktív témák...
- -61% Samsung Galaxy Book2 Pro 13:i5 1240P,8GB,256GB,13.3" AMOLED,400nit 100%sRGB,WiFi 6E,csupán 870g
- Amazfit GTS 2 új! (nem a mini)
- -62% HP EliteBook 845 G7 (840 G7):Ryzen 5 4650U,16GB,512GB SSD,vilI.MAGYAR bill.,Bang&Ol.,Win11ProHU
- Több db HP Thunderbolt dock 230W G2 230W -os töltővel MONITORCENTER
- Philips Evnia 42M2N8900 Gamer Oled Monitor!42"/4k/138hz/0,1ms/Freesync-Gsync/HDMI 2.1/TypeC/Ambiglow