[Videó] Felhőből két lábbal a földre - Kollár László (Cloudera)

Címkék

A felhő alapú számítástechnika alapvetően drága. Ezen tény felismerése egy kisebb mérvű visszarendeződést indíthat el a saját adatközpontok felé, de már magával hozván a felhő működési modellt. Ennél fontosabb, hogy ez a felismerés egy változást indít majd el a nagyvállalati informatikai és felhasználói körökben arról, ahogy számítástechnikai erőforrásokról gondolkodnak. Az IT valóban egy tömegáru, de tisztességes árcédulával. A fenti eseménynek két mozgatórugója van: A számítási és adattárolás feladatok úgy mentek át egy merőórával szerelt környezetbe, hogy közben a felhasználási minták változatlanok maradtak. A nyilvános felhőszolgáltatók mindössze felfedték a kényelmetlen igazságot a vállalati IT fogyasztási szokásokról. A másik ok a felhasználói szempontból végtelen kapacitásokhoz való azonnali, kontroll nélküli hozzájutás lehetősége mellett, ami óhatatlanul vezetett a fogyasztás növekedéséhez. A nagyvállalati IT technikai, számviteli és érzelmi okokból „hagyja égve a villanyt”. A problémára (mint az élet szinten minden kihívására) két válasz adódik: Vagy harcolsz ellene, vagy elfutsz előle – azaz visszaviszed a feladatot a saját adatközpontodba. Az előadás az okokat tárja fel részletesen, illetve javaslatokat tesz arra, hogyan oldjuk meg ezt a problémát anélkül, hogy visszaforgatnánk az idő kerekét.

(A videó a 2019. június 18-i HWSW free! üzemeltetői meetupon készült.)

Hozzászólások

Vagy csak egyszeruen elkezded normalisan hasznalni a felhot, egy csomo embertol elveszed a jogot hogy minden szart elinditson, az osszes dev rendszert szigoruan elkulonited ahol tisztan elvalaszthato a prod koltsegtol, bevezetsz rendszeres cost analysis taskokat, elkezdesz Cloudflare-t hasznalni hogy levidd az adatforgalmi koltsegeidet, elmesz multi-cloud iranyba terraform segitsegevel es az olcsobb felho szolgaltatotol vasarolsz, meg meg 100 dolgot leirhatnek.

A vissza az adatkozpontba egy naiv latszatmegoldas, ugyanugy a nyakadba szakad a DC osszes nyugje hardverfenntartassal, raid monitorozassal, halozatmernokokkel, kutyafaszaval, plusz meg bevezetsz egy jo vastag munkaeroigenyes (tehat draga) extra reteget a fizikai vasak fole hogy privat cloud elmenyt tudj adni.

Sok sikert :)

És ezzel ki is nyírtad a céged innovációs képességeit. A maradék alkalmazott biorobot lesz egy agyonszabályzott környezetben. Végeláthatatlan meetingek soraiban osztják az észt és egy egyszerű TASK-hoz is képződik 500 ticket amin kismillió emberen megy keresztül. A költségek meg hamarosan elszabadulnak mert mindenhez külsős segítség és tanácsadás kell akik persze nem pusziért dolgoznak. Aztán az országspecifikus dolgot nem is említettem mikor pl megtervezed a felhőd aztán kiderül, hogy vannak országok amik a náluk képződött adatokat nem engedik ki az országukból.

Elnézve a mai agyonszabályozott cégeket meg is értem miért kezd a még nem kiszervezett emberek élete a futószalag melletti melósok életére hasonlítani. Ott ülnek egy gép előtt amin fut az SAP az Excel meg a Teems és akkor mikor a cég indít egy "Good Idea" projektet a leginnovatívabb ötletek kimerülnek abban, hogy több kávégép kell és ne nyomtassunk mert ártunk a környezetnek (persze hol máshol ötletelnének kb annyi lehetőségük maradt).

Volt szerencsém végig nézni egy ilyen "fantasztikus" innovációt. Jelenleg nekünk csak augusztusig plusz 12 millka volt amit kifizettünk IT szolgáltatásokért (ez csak a szürkeállomány amiért csengettünk plusz a 200 kilométerről érkező Pistike akinek ha kér van joga nyomtatót bevinni a rendszerbe egy ilyen kiszállás 100 nettó, Meraki, Fortigate, Azure szakik mérnöki díjai horror).

Persze a mesékbe úgy lehet ahogy mondod, csak épp nincs elég szaki nincs elég tudás, emiatt a legtöbbször a felhő nem, hogy olcsóbb hanem radikálisan drágább lesz.

De persze oké ez a trend. Bánom is én.

"Aztán az országspecifikus dolgot nem is említettem mikor pl megtervezed a felhőd aztán kiderül, hogy vannak országok amik a náluk képződött adatokat nem engedik ki az országukból."

Ott ahol valóban van ilyen restrikció és jelentős gazdasági erővel bír az ország, már vagy telepítettek a nagy felhőszolgáltatók DC-t, vagy éppen folyamatban van.
Egyébként érdekes, hogy ezekben az országokban sem ütközik törvénybe, hogy a kérdéses adatokkal a világ másik felén dolgozó emberek dolgozzanak. :)

"Elnézve a mai agyonszabályozott cégeket meg is értem miért kezd a még nem kiszervezett emberek élete a futószalag melletti melósok életére hasonlítani."

Ez gyakorlatilag minden szektorban így van. Mindenhol cél, hogy részfeladatokra bontsanak fel egy munkafolyamatokat.
Nyilván ez előbb utóbb vagy automatizálva lesz, vagy keletre költözik.

"nincs elég szaki nincs elég tudás, emiatt a legtöbbször a felhő nem, hogy olcsóbb hanem radikálisan drágább lesz."

Pont a magas automatizáció és a felhős szolgáltató által biztosított support miatt jár kevesebb élőmunkával.
Itthon azt sem értem már igazán, hogy a kis és középvállalatok honnan tudnak megfelelő minőségű IT munkaerőt találni, ha ez a globális multiknak is nagyon nehezen megy.

Mindenhol cél, hogy részfeladatokra bontsanak fel egy munkafolyamatokat.

Jaja, es ezzel az enterprise architect-ek foglalkoznak. A baj csak az, hogy gyakori, hogy a loser coder osszehaverkodik management-el es csinalnak belole egy architect-et. Aztan mikor raszakad az egesz cloud, hirtelen kapkodja a fejet, persze roppant magabiztosan, mert o ugye 'lead'. :(

 

a kis és középvállalatok honnan tudnak megfelelő minőségű IT munkaerőt találni, ha ez a globális multiknak is nagyon nehezen megy.

Ugy, hogy a nagy cegek borzaszto rugalmatlanok, es kis porszem vagy a gepezetben, kvazi futoszalagos munkas.
Kurvasok 'munkatarsad' van, szemelyesseg teljesen elveszik.
Okos menedzserek jonnek az eszelos terveikkel, otleteikkel, amiktol egy kis ceg mar reg bedolt volna, a nagy multi is csak a sulya miatt kepes meg talpon maradni.
A nagy multik "termekei" tipikusan agyonarazott kotyvalek szar, amit a sajat alkalmazottaik is csak azert vesznek, mert 50%-os kedvezmenyt kapnak ra.

Ez sokaknak nem tetszik.

(tisztelet a kivetelnek!)

Mindenhol cél, hogy részfeladatokra bontsanak fel egy munkafolyamatokat.

Jaja, es ezzel az enterprise architect-ek foglalkoznak. A baj csak az, hogy gyakori, hogy a loser coder osszehaverkodik management-el es csinalnak belole egy architect-et.

Amiről én írtam, az organizációt érintő választás, amit nem egy ember tervez meg és dönt el.

hát onnan, hogy nincsenek a felhőben. Amúgy attól, hogy a VAS-al nem kell foglalkoznod a folyamatokat ugyanúgy végig kell rugdosnia egy hozzáértőnek vagy legalább egy olyannak aki tudja mit szeretne és van lovéja kifizetni a külsős mérnököket. Ha ez a szaki nem érti a felhőt akkor nem költöznek oda. Amúgy felhőn kívül is rongyá lehet mindent automatizálni.

 "Amúgy felhőn kívül is rongyá lehet mindent automatizálni."

Nagyon nem mindegy, hogy ezt készen kapod-e vagy neked kell fejlesztened és üzemeltetned.

Egyszerű példa: az elmúlt 1 évemben egy olyan szolgáltatás fejlesztésével foglalkoztam, ami az igények függvényében CI / CD rendszerhez előre konfigurált virtuális gépeket provision-el private cloud-ban, majd a Job végrehajtása után revertálja őket snapshot-ból.
Egy csomó körítés kellett: update management, monitoring, cmdb, penetration tesztek..etc.
Összességében több tízmilliós költségről beszélünk.

Majd hirtelen előállt a Microsoft a Scale Sets-el és leesett az állam. 

 

Igen ebben tökéletesen igazad van. Tele van az Azure olyan kész megoldásokkal amikkel régen kismillió idő elment. Mondjuk szerintem a helyi informatikusokat nehéz kiváltani pláne egy termelő cégnél, csak nem tudom mennyire bejövős egy mindenhez értő McGayvernek, hogy eztán ticket és csak részekhez lesz joga vagy esetleg részt vehet a tervezésben a helyismeretének köszönhetően (velem ez történt már teljesen felhőben vagyunk).

Égve hagytad a folyosón a villanyt.

Érdekes előadás, köszi! Szerencsére nem érint a terület, de jó tudni ezekről a problémákról.

Lol... Emlékszek pár éve, mikor mindenki minden mindent a felhőbe tett, itt a hupon is meg máshol is napóleoni hadjáratként és sikerekes zsákmányszerzésként marketingelték, hogy a szutykos lokális szerverekről a hajjdejó és hatékony meg olcsó meg gyors cloudba költöztek, továbbá ezzel minden probléma megoldódik és ettől ők magasabbak és jobban, aki marad saját szerveren az alsóbbrendű. Én már akkor is kiröhögtem ezeket. Csak nem rájöttek, hogy nem való mindenkinek a felhő és nem kell mindent ész nélkül feltolni?

"Sose a gép a hülye."

Szerkesztve: 2020. 10. 13., k – 14:11

Sajat CPU nem feltetlen dragabb.
Ha csak a vas arat nezuk a cloud draga, kb lista ar haromszorosat szoktak merni a vasat ,
amit nagyon nem lista aron vettek ..

Otthon ha annyira sok CPU nincs amiert meg hutest is kelljen fizetni (legkondik),
sokkal olcsobb lehet az otthoni CPU, mar ha nem csak megvetted es kihasznalatlanul ul.

Nyilvan vannak mas kolsegek is 30% amazon/azure
haszon meg akkar realis is lehet.

Eleg sok marketing anyag a tenyleges szolgaltatas osszes koltsegeinel a vas arat relative  alacsonyra becsulik.
Gyakran van nemi csusztatas, hogy az operacios koltsegekebol, menyi megy le ha cloud-ba megy az ember,
az alkalmazst meg mindig felugyelned kell es ritkan szamoljak kulon mi az ami vas uzemeltetesi ember koltseg
es mi a vason futo softwares ember koltseg ..

Ha sajat DC-t jol csinalja az  ember, nem hinnem, hogy megeri 30% -ot a szolgaltatonak adni,
habar ritkan vannak a dolgok jol csinalva ..
Nyilvan kisebb jatekoskent, nem tudsz mindent megcsinalni, amit a nagy clouderek, de nincs is mindenre szukseged .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az otthoni infrastruktúrát nincs is értelme a nagy cloud-ok által nyújtott minőséggel összevetni.

A szoftver licencek egyébként jelentős költséget jelentenek a cloud-os VM-ekben és köthetsz egyedi szerződést, illetve a fizikai szerver teljes életciklusára (3 - 5 év) jelentős kedvezményeket adnak publikus ajánlatokban is. 

"Az otthoni infrastruktúrát nincs is értelme a nagy cloud-ok által nyújtott minőséggel összevetni."

Attol fugg,
Ha dolgaidat leginkabb dolgok kiprobalasara es test/dev envnek hasznalod, akkor van.

Ha othonra megeveszek egy `harmad annyiba kerulo valamit`, meg mindig ott  van, hogy
tenylegesen mennyit hasznalom.

Itt is erdelemes elgondolkzni, hogy ha nagyobb env evente csak 4 szer kell,
erdems -e megvenem ..
 

Ugyan ugy melo helyen, ha van egy dev/test tier, hasznalja azt barki is munka idon kivul?
Egy het 168 ora ~40 ora munka idovel (23%) , nyilvan este valogatja
de dev/test/stage envek  munka idon kivol legtobbszor csak uresen ulnek a legtobb helyen.

Ha 10 business appot kell alkalmankent fejlesztgetni egytlenen fejlesztonek,
erdemes -e mind 10 nel futtatni allandoan egy-egy  kulon  dev envet ..

Nem veletlen, hogy az (Iaas )cloud foleg dev/test,  CI, batch operation -re van inkabb hasznalva.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Sem a felhő, sem a saját adatközpont nem drága. Drága az, amikor megveszel vagy bérelsz olyan erőforrást, amit nem használsz értelmesen (üzleti értéke nulla).

A rugalmasság mindent visz. Ha lazán csatolt szolgáltatásokra építesz, tudsz költözni vagy egyes elemeket cserélni.

Holnapra kell? Publikus SaaS

Holnap után is elég? SaaS+PaaS + némi saját kód, ami kiemeli a szolgáltatásod egyediségét.

Már szépen bejáratott a szolgáltatásod? Profilba vág az IT? Ha igen, az átlag terhelésre kezdhetsz saját infrát építeni, a csúcsokat hagyd a felhőben. Ha nem, akkor nem akarsz saját IT-t. Tuti. 

" a csúcsokat hagyd a felhőben. " , magyar vagy ceges belso szolgaltatas viszonylatban
van -e olyan hogy tenylegesen erdekelne (csak) a csucsok kivitele a felhobe ?

Nagyon erdekesen hangzik egy marketing eloadasan, de tenylegsen lenne -e ertelme ?

Rendszerint a szarul megirt appok-sem ugralnak annyit egy kozepes nagy valalatnal (~1GUSD eves bevetel, nem IT sector),
hogy ez tenyleg megerje. Jol megirt appoknak, meg minek auto-scalelni akkar merre :-) .

Amin lehet sporolni, sajat vegy kulso clouddal, az a HA nodok nem meg vetele.
Pl. 2~5 nodra osztod szet terhelest, es egy halala nem okoz gondot,
akkor a siman "veszel" egy masik nodot eldobod a roszat es kesz.
Ha nem (horizintalisan) megoszthato a folyamat, erdemes elgondolkozni azon,
hogy baj eseten siman leloved es epitesz egy uj nodot. Lassabb a helyre -allas, mint egy hot-standby -al,
de vasak manapsag ritkan halnak es a lassabb, nem feltetlen jelent sokkal lasabbat, ha ugy csinaltad meg ..
Technika letezett cloud era elott is, csak nem volt neve  es mindenki jobb HA -t akkart, nem erdekes menyibe kerul ..

Az autoscale a legtobb estben, inakbb hangzik olcso HA -nak, mint tenyleges
nagy terheles kibirasra kitalalt valami , mert az igazan "nagy" terheles nincs is jelen a legtobb cegnel ..

Reszleges kivitel altalaban, azert tortenik, mert kozelbb van a cloud szolgaltatas clienshez (frontend, cache, CDN, edge side include ..)
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.