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

• #28662 Dißnäëß veterán haddent #28607

  Új Válasz 2019-10-01 22:33:32 #28662

  Ú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

  

  Dißnäëß

  veterán

  válasz haddent #28607 üzenetére

  Az esetek többségében - kivétel mindig lesz, lehet nem is kevés - a mögöttes folyamatok sem mindegy, milyenek.

  Például egy ~100+ "gépes" (VM-ek és konténerek vegyesen) teljes IT stack-et Azure-ben felépítve és üzemeltetve az erőforrás igénye sem összemérhető egy on-premise private cloude-éval, a hozzá adott csilliárd analitikáról és automatizálhatóságról meg n+1 nézetről nem is beszélve.

  És aki azt mondja, nem tökéletes, meg itt-ott beteg, szar, izé ? Hát én még private cloud-ból sem láttam olyat, amibe nem lehet belekötni.

  De a folyamatok mögötte akkoris... private cloud-nál vagy urambocsá, annak "elődjénél", az on-premise (akár DC-ben is) lévő üzemeltetésnél waterfall gigaprojektek verekednek iszonyú hiperdilettáns ITIL-helpdesk-szolgáltatási szinteken és xyz Service Management / Ticketing tool-okon keresztül mind hardver erőforrásért, mind élőember (know-how) erőforrásért, és mire elér valami egy úgy-ahogy értékelhető stádiumba, már újra kéne tervezni lassan a projektet, mert a világ odakint közben fordult kettőt. Egy tényleges public cloud mögött pedig (jó esetben, ha alkalmazható, de nem kötelező) egy agilis csapat valamiféle formája van, relatív nagy sebességű reakciókkal változó üzleti igényekre, amiket rendszerben is le tudnak követni és nem úgy, hogy feladom ticket-be a Change Request-et, vagy L1 felveszi nagylassan-tökhanyagul az incidens ticket-et és onnantól várunk heteket, néhol hónapokat hogy történjen valami a hülyebuta-erőforráshiányos-nagyájtín a háttérben, hanem kb. behúzza PO a sprintbe, valamilyen prio-val ellátja oszt a devops összeüti neki öt kattintással, mondjuk egy új UAT környezetet, mert (ahogy az lenni szokott) a tesztelők épp elfogytak egy új feature tesztelésére tervezett környezetből, "mert azon még az xy release-be menő akármi egyéb fut " épp a Tosca-val, Katalonnal, vagy kőbaltával fullmanuálban. Ez agilisben egy szó szerint agilisen, gyorsan reagálva történve van lekezelve, hozzá egy ezzel kompatibilis Azure-ös pár kattintásos dologgal, amikor fogom az egyik korábban összeállított template-et (vagy az élest "replikálom", ez a legjobb, konzisztens lesz a teszt, abból pikkpakk beröffen egy újabb környezet (legyen az VM vagy konténer), felkonfigolódik, igény esetén még a frissítések is lejönnek rá, hálózat, környezeti változók, minden fiszfasz kialakul és ready to serve. Ott már nincs az, hogy az üzemeltető alvállalkozó embere túrja egy hétig meg konfigolgatja, aztán úgyis elakad, úgyis hívja Bélát a fő architektet, aki morogva de kisegíti, közben eltelt 7 nap.. Ez élőben úgy néz ki, hogy gomb megnyom, közben kimegyünk kajálni a közeli kínaiba, és mire visszaérünk, az infrás átkurjant az asztal fölött a tesztelőnek, hogy nyomhatjátok, közben JIRA-ban az erre kanban board-on felvett standalone issue-t gyorsba bekommenteli és cső, Done.

  Szóval a public cloud szvsz nem CSAK magáról a technológiáról szól, hanem a mögé tett folyamatok gyorsaságról is. Arról nem beszélve, hogy ha a 100 gépből 20-30 teszt és ezek lefutnak és van kis levegő "semmittevés" teszt oldalon, ha épp nem kell az erőforrás, lelövi az ember és a stopper megáll: nem fizet érte az ember. Ha pedig kell, akár csak pár órahosszára is, akkor megint "play gomb" és mehet a boogie, pár plussz dolcsiért.

  Összességében a private cloud-ban megoldott public cloud-os tech sima mezei installációként még nem adja mindazt a plusszt, amit tényleg ad egy public cloud. Persze ha nagyon kapálózik az ájtí főfejes, jöhet az MS felajánlani, hogy helybe letelepíti az ezsört az összes funkciójával együtt on-premise, csilingel is a kassza, ez szép megoldás lesz (és mindenki jól jár hehe, szép kis ország).. , csak ha 100 gép helyett 20-ra mondjuk nincs szükséged, mivel Nálad a host, az attól még bekapcsolva marad és fogyaszt, van egy költsége, míg a public cloud-ban a leverage effekt érvényesül, azaz tojsz magasan ezekre, ha nem használod az aktuális gépet pár órára vagy napra, lelövöd és kész, annyival kevesebb a költséged is, a többi meg a provider dolga (PaaS és ház a szilícium völgyben azért előrébb vannak tőlünk pár évvel). Az más, és mindenki döntse el magának, hogy a működő gépekért elkért költségbe beárazza-e a cloud szolgáltató e költségeket szétterítve - hogyne, nem hülye. De azért összességében még mindig van, amikor éves szinten több tíz millióval (!) jobban térül egy fully fledged Azure installáció, legyen az kicsi vagy nehézsúlyú k*sok gépes birkózó, mint egy on-premise private cloud csilliárdért, ami ennek tizedét sem (!!!) tudja... ahol a beszerzéstől az IT vezéren vagy CEO fővezéren át sokak kapnak vastag borítékot a beszállítótól, hogy ugyanmár, vegyétek a mi hardverünket és tessék-lássék supportunkat, segítünk, jóleszaz, egy kis Cisco ide, egy kis F5 oda, egy rack ide, egy EMC amoda, jólvan, buksisimi... A kassza meg csilingel..

  Mondom ezt elfogultságmentesen kő linux pártiként és kicsit (de nem vakon) anti M$-esként.

  Baszottul csak előre van út, szerintem. Erősen felhasználásfüggő, mi mire kell és megfelelő, nem jó mindenre sem egyik, sem másik megoldás, de azért a public cloud-ot nem tudnám most úgy leírni és lehúzni, mint ahogy akárcsak 2 éve is néztem rá.

  A motyók több mint felét már egy ideje cloud szolgáltatóknak gyártják és ők is veszik, illetve lassan ők lesznek abban a helyzetben, hogy keresztbe-kasul bevásárolnak beszállítókból, maguknak ...

  Át kell állni fejben, nincs mese.

  POKE 16017,44 ..... SYS 2077

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