Új hozzászólás Aktív témák

• #5 bambano titán #45997568 #2

  Új Válasz 2019-01-17 18:16:29 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  LOGOUT blog

  válasz #45997568 #2 üzenetére

  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

• #32 frescho addikt #45997568 #31

  Új Válasz 2019-01-17 22:49:34 #32

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  frescho

  addikt

  válasz #45997568 #31 üzenetére

  Kiszerveztétek a vas beszerzést, üzemeltetést és még sok mást, ezeknek az SLA-ját is mástól várjátok el.

  Ez jó döntés is lehet. A lényegre tudtok fókuszálni és rugalmasan fejlődni. Kis forgalom, kevés bevétel mellett a kiadás is alacsony, jobb a méretgazdaságosság.

  De van amikor security vagy más szempontok miatt ez nem éri meg. Kezdődhet onnan, hogy ti magatok vagytok a cloud szolgáltató. Az is lehet, hogy szerződési kötelezettség az adatok házon belüli kezelése. Végül lehet, hogy a cloud szolgáltató csak egyedi ajánlatként tud megfelelő teljesítményű gépet biztosítani kb 3x áron 2 hónap átfutással.

  Szóval mindennek meg van a maga helye, nincs üdvözítő megoldás. Nállunk van több tucat cloudban futó mikro service ahova nem kerülhet ki csak anonimizált adat, private cloud és igazi monolitikus saját adatközpont is az érzékeny adatoknak.

  https://frescho.hu

Új hozzászólás Aktív témák