Olyan egyszerű a felhőben a potikat felcsavarni ...

HUP

Bárki, aki már dolgozott felhős környezetben, pontosan tudja milyen egyszerű a problémákat újabb és újabb erőforrások betolásával megoldani. Az eredmény ismert: pénzégetés. Erre válaszul született meg a FinOps (szervezetileg a Linux Foundation égisze alatt), vagyis a felhős költség optimalizálás, mely azokat a praktikákat, mérési és devops módszereket fogja össze, mellyel kontroll alatt tarthatók a cloudos költségek. Május 18-án elindul az első hazai FinOps képzés 6 alkalomban, 18 órában, a szokásos online formátumban, munkaidő után.

Ugyanitt 8 alkalmas, 24 órás online Ansible alapozó is keresi gazdáját. További részletek »

( LCoder | 2022. 04. 28., cs – 13:26 )

Normális körülmények között a felhõre átállást eleve számolgatás elõzi meg. Nagyon hülye az, aki úgy megy bele a felhõbe, hogy nem nézi meg, hogy ez neki mennyibe kerül most, és mennyi lesz a felhõbe migrálás után.

És általában igazán ott érdekes ez, ahol a teljesítményigény ingadozik, Pl. egy országgyûlési választási rendszer 4 évenként egyszer van csúcsra járatva, így nem feltétlenül éri meg az ehhez szükséges kapacitást 4 évig fenntartani (még ha nem is kapcsolod be, a gépek akkor is amortizálódnak, és áll bennük a pénz).

És mi van akkor, ha én egy startup vagyok, aki tud webappot írni, de sem a világ minden táján gyorsan elérhető, geo-redundáns rendszert sem használat utáni pénz beszedést nem tud egykönnyen megvalósítani. Így inkább egy hyperscalerre és a marketplace-ére bízza mindezt?

Fizetnék neked egy sört, ha egy konkrét esetben pl. Azure-ban +/- 100 dodó per hó hibahatárral meg tudnád mondani mennyi lesz a havi számla egy közepes méretű cégnél. Nekünk amikor ezzel kellett foglalkozni, többünknek sem sikerült retrospektíven sem kitalálni a havi számla hogy jött ki. Pedig csak 1 szaros hálózati szolgáltatást raktunk ki oda kb. 30 szerverrel. Én magamra vállalom h. gyengeelméjű és hülye vagyok hozzá, de volt kitartó (és értelmes) kolléga aki nagyon ráfeküdt, de neki sem jött ki a matek.

Szóval qrva könnyűnek hírdeti a költségek nyomonkövetését a msft. Aztán mikor rájössz h. semmi nem csak annyiba kerül, hanem a 2-3x-ba mint ahogy hírdetik (hint: apróbetű, ill. követhetetlen kategóriák és szintek végtelen kombinációja és mélységei), akkor belátod h. nagyon nem olyan olcsó a klód, mint ahogy a msft sales-es rátok tukmálta. Ha nem érné meg nekik (msft), nem csinálnák amúgy sem.

Az "AWS EC2 instancet véletlenül bekapcsolva hagytam, most homeless vagyok" meme-ek sem ok nélkül születtek.

Némi tapasztalattal "kilóra" meg lehet becsülni, hogy mennyibe fog kerülni valami az AWS/Azure/GCP-ben. A tapasztalat ahhoz kell, hogy pl. lásd, hogy mikor számít a hálózati forgalom költsége meg mikor a computing költsége, melyik paraméter alapján lesz nagyobb a költségtétel, miket érdemes beleszámolni a becslésbe. Lehet mindent is - de az elég sok munka. Ha ennél pontosabb kell, és mondjuk +/- 100 dollár hibahatáron belül akarsz maradni, mert 100 dollár különbség feltűnik, akkor sokkal inkább menj a PistikeComputer Bt.-hez hostingot venni, mint a nagyokhoz, jobban meg fogja érni mindenkinek.

A felhő tök jó dolog, de nem mindenre jó.

(Amúgy ha valakinek kell FinOps-hoz is értő ember, akkor keressen meg, értek hozzá, tudok adni referenciákat is. :-D )

Gyanítom nem az USD 100 a probléma, hanem meg kell adni a pénzügyi tervhez az éves várható költségkeretet, és ezzel terveznek. Ha felül lövöd, akkor a csodás működési elvek miatt inkább érdemes többet költeni, hiszen kellenek a teszt VM-ek. Ha erősebben alultippelsz, akkor jöhet a szönyegszéle, hogy nem erről volt szó, és hogyképzeliazájti. Ha meg esetleg az eddigi sima saját infránál jóval többe kerül, akkor pedig pláne jogossá válik a kérdés. Arról nem beszélve, hogy az USD alapú árazásban most bazinagy árfolyam kockázat van, és sikerül elnézni a költséget, akkor még ez is rátesz egy lapáttal. Pont 1-2 napja néztem, hogy kb. 1 hét alatt 342 forint körülről majdnem 360-ig szaladt a forint.

Ez mind igaz, de eddig nem erről volt szó.

Egyébként ha tudom, hogy mit kell csinálni, akkor viszonylag nagy pontossággal meg tudom mondani, hogy mennyibe fog kerülni egy felhőszolgáltatónál. Ha nem tudom mit kell csinálni, akkor meg nem. És ez hajszálpontosan ugyanígy van on-prem infránál is.

Ha a felhőszolgáltató mondjuk euroban számláz, akkor euroban tudom megmondani az árat viszonylag pontosan. Forintban nem, mert halvány lilám sincs róla, hogy milyen lesz a forintárfolyam, cserébe ezt pl. kicsit sem érzem IT feladatnak.

Te lehet, hogy a felhők árazásával töltöd a munkaidőd, de amikor van 800 Subscription, több tízmilliárd Forint értékű éves fogyasztással és többezer felhasználóval, akkor felértékelődik a költségeket optimalizálása. Olyannyira, hogy már a szükséges erőforrás létrehozásánál érdemes automatizáltan kezelni.

Ennél egy nagyságrenddel kisebb rendszerekkel dolgozom (~100 AWS account az orgban, ~10 millió USD éves költség), és igen, már ehhez is kell rendes tooling. Annyi különbséggel, hogy itt a cég úgy döntött, hogy ne legyen időhúzás azzal, hogy előre kell becsülni meg jóváhagyni a költségeket, hanem erős utólagos kontroll legyen, és legfeljebb egy hónap után jöjjünk rá, hogy valami többe kerül, mint kéne. Az egyhavi veszteséget meg benyelik - fontosabb a time-to-market.

Ez egy érdekes kérdés.

A felhős szolgáltatások közül a "hagyományos" dolgokat, pl. virtuális gépeket _esetleg_ meg lehet oldani így, de a managed szolgáltatások többségének nincsenek 1:1 megfelelői a többi szolgáltatónál. Pl. az AWS-ben egy tök jó szolgáltatás az SQS - de mit adnál helyette Azure-ban, ami pont ugyanazt tudja? Vagy mi az Azure Application Gateway pontos megfelelője a Google-nél? Hasonló szolgáltatások vannak, és valószínűleg lehetne a szolgáltatásoknak valami metszetére építeni valamit, de szerintem ez nem érné meg. Kicsit olyan, mintha szeretnél egy toolt, ami linuxot meg Windowst is tud telepíteni egy közös konfigfájl alapján.

Szóval nem.

Nem teljesen egyre gondolunk, engem egy olyan layer érdekelne, amivel a userek tudnak erőforrásokat provisiolni, a platform üzemeltetője pedig approve-okat, compliance check-et, konfigurációt, költségellemzést tud beépíteni.

Jelenleg saját fejlesztésű megoldást használunk vmware felett hasonló célra az on-prem rendszereken, cloud-ban kvázi szabad a gazda Subscription-ön belül, nem képesek a belső folyamatok ezt igazán lekezelni, pár security beállítás van csupán scannelve.

egyreszt, amit te igy megbecsulsz, az nem egy komoly rendszer, nem egy modern stack. 

masreszt, nem az a muveszet, h megbecsultem es annyi lett. mi van akkor ha mindig is tulbecsulted es annyi lett? 

a dolog ott kezdodik, hogy egy mar felhoben mukodo es fejlodo cegnek kontroll alatt tartod a koltsegeit, metrikaid es vizualizacioid vannak, latod az anomaliakat, es tech oldalrol olyan csapat van mogotte, akik elolvassak a platform frissiteseit, a valtoztatasokat kiprobaljak, es szemletlet szinten megnezik, hog egy ujdonsagnak vagy beallitasnak lehet e hatasa a koltsegre, vagy kepesek jelezni, hogy erdemes lenne atallni mondjuk k8s-re mert a granulaltabb skalazasnak koszonhetoen par ezer dolcsit nyerhettek ha nem virtualis gepeket hasznaltok. ez nem egy one man show, es nem is a 100 dollarosok birodalma.

Viszonylag nagy és komplex rendszereket csinálok és üzemeltetek felhőben (milliós nagyságrendű concurrent userrel webshopok és környékük, specializált számlavezető rendszerek), és nyilván sokkal menőbb stacken, mint az EC2-k tömege. És valóban nem egyedül csinálom, mert az túl sok munka lenne. :-)

Viszont tényleg van némi képem a FinTech próbálkozásokról, a toolingról is, ha szép grafikonokat akarsz látni meg ilyenek. Privátban szívesen beszélgetek a témáról, ha van rá igény.

a tortenetnek egyfajta bagetellizalasa, hogy hulye az, aki nem szamolta ki elore. egyreszt mar ez sem egy egyszeru feladat egy bizonyos szinten, es foleg nem mukodes kozben kezbentartani egy nagy es komplex IT-nal, nagy skalazodassal.

en sem gondoltam ezt korabban raketatudomanynak, de most eleg sokat beszelgettem azzal a nehany arccal aki ezzel itthon komolyabban foglalkoznak kicsiben es extra nagyban, es ujraertekeltem. :) egeszen kis meretben is ugy porognek el a szazasok pusztan par rossz valtozon, hogy orom nezni, es komoly skillset kell hozza, hogy ezt egyaltalan felismerd. aztan ott van az a szint (van itthon ilyen!), mikor havi kozel 1 millios dollaros a cloud koltseged van. ott a finops mar egy egesz komoly modszertani dolog, es a cloud hasznlat kontrolljat a teljes szervetere ki kell terjeszteni.

De siman, viszont a 'nagy nemzetkozi ceg' budapesti supporttal meg nem jelenti azt hogy magyar a ceg. Nyilvan hiaba van a Revolutnak is tonnaszam lengyel supportosa, attol meg nem lengyel ceg.

Par kezunkon megszamolhato a nagy itthoni cegek szama, akik valoban itthoniak, es beleferhet nekik havi 1m $, es ezert lennek kivancsi hogy miben utaznak.

( andrej_ v | 2022. 04. 28., cs – 21:40 )

Azért amikor folyamatosan egyszerű projekteknél állandóan "sz*rarszerver"-ezik a kedves fejlesztő, és mindenféle FinOps buzzword nélkül semmilyen érdemi teljesítmény optimalizálásra nem hajlandó, akkor nem tudom mit várnak FinOps-ék. :) De abbahagyom, mert erről már volt pár szál.