(Kollár László (OTP Bank) előadása a HWSW free! meetup-sorozat 2021. december 9-i cloudos tematikájú állomásán hangzott el.)
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
https://www.youtube.com/watch?v=2yKLnfYqOIs
Az ott Harry Potter kozepen?
- A hozzászóláshoz be kell jelentkezni
nyilvan :)
egyebkent igen, innen van az eloadas cime.
- A hozzászóláshoz be kell jelentkezni
Van még egy roadblock, amit érdemes megemlíteni szerintem: kéne tudni angolul annyira, hogy ne érts félre dolgokat. Több fejtörést okozott ez nekem, mint a 2. helyen szereplő, "a fejlesztőnek magáévá kellene tennie a The Practice of Cloud System Administration könyv tartalmát". :-)
- A hozzászóláshoz be kell jelentkezni
+1 ha te is csak az index kép miatt indítottad el a videót! :)
- A hozzászóláshoz be kell jelentkezni
Ertekeltem volna, ha jobban kifejti, miert kell a cloudba menni. "Onnan jon az innovacio" - ezt nem ertem. Gyorsabban skalazodik? Ok. Ha penz nem szamit (ahogy mondja), akkor az on-prem kapacitas duplazasa sem lenne problema, nem?
- A hozzászóláshoz be kell jelentkezni
Az on-prem kapacitást megduplázni ha ultragyors vagy is 6 nap. Egy OTP méretű cégnél jó esetben 6 hónap. A felhőben 6 perc. Az OTP ez alapján nagyjából 8640x gyorsabban tudja megduplázni a kapacitását a felhőben, mint az on-prem géptermeiben. Ez releváns gyorsulás.
- A hozzászóláshoz be kell jelentkezni
Milyen gyakran van szukseg a kapacitas megduplazasara?
- A hozzászóláshoz be kell jelentkezni
Érdemben változik ez a szorzó, ha nem duplázni kell, csak mondjuk 10%-kal növelni?
- A hozzászóláshoz be kell jelentkezni
Milyen szorzó?
Nem ismerem az OTP belső rendszereit, igényeiket - segített volna, ha az előadás mond példát.
Egyik oldalt (a földön, ahogy az előadó mondja), ott a klasszikus infrastruktúra, (állítólag) vertikálisan skálázható gépekkel. Egy adatbázis failoverrel, néhány frontend szerver, például. Egyszerű szoftver, egyszerű üzemeltetés.
Másik oldalon a cloud, gyors horizontális skálázódás, alapjaiban más szemléletű szoftver, más/bonyolultabb állapotkezelés (distributed consesus pl), load balancing stb., más képességeket igénylő üzemeltetés.
Azt el tudom képzelni, hogy a googlenek, twitternek, facebooknak, netflixnek miért van szüksége az utóbbira.
Nyilván fantáziátlan vagyok, de az OTP esetében nem tudom elképzelni, pláne, hogy meg vannak még szórva rengeteg szabályozással. Szóval tényleg érdekelne, hogy nekik ez hogy lesz jó. Egyik napról a másikra megduplázódik a netbank terhelése, és bővíteni kell? Hirtelen nyitnak még 50 bankfiókot, és bővíteni kell? Durván felpörög a hitelpiac, és olyan ütemben kell elbírálni, hogy bővíteni kell? Nem tudok ostobább példákat mondani, segítsetek.
- A hozzászóláshoz be kell jelentkezni
Egyik napról a másikra megduplázódik a netbank terhelése, és bővíteni kell?
Ennek kicsi az esélye, de ennél kisebb mértékű szezonalitás simán lehet. Fizetésnap körül extra terhelés, éjjel minimális forgalom, reggelente többen kérnek számlatörténetet, vagy mittudomén.
- A hozzászóláshoz be kell jelentkezni
Ezért vetettem fel ellenérvként: év elején duplázzák az *eddig kihasznált* kapacitást (pénz ugye nem számít), és akkor biztos nem lesz gond 1 évig, ha 10%-t nő a load. Cserébe az összes szoftver, üzemeltetési tapasztalat marad.
Ha meg nem ilyen triviális a terhelés változása, akkor az talán megér néhány mondatot az előadásban, nem?
- A hozzászóláshoz be kell jelentkezni
Ezt szépen ki kell számolni, hogy a konkrét esetben melyik konstrukció éri meg jobban – nem lesz rá általános igazság. Szerintem a netbank rövid távon jelentős szezonalitást mutat, lehet minden év elején a tavalyi csúcsterhelésre méretezni, de szerintem nem éri meg. Vagy lehet, hogy megéri, ezt majd az OTP eldönti. :)
pénz ugye nem számít
Én nem láttam a videót, de ezzel kapcsolatban kicsit szkeptikus vagyok :)
- A hozzászóláshoz be kell jelentkezni
akkor az on-prem kapacitas duplazasa sem lenne problema, nem?
Cloudban egyfajta axioma, nem vertikálisan (feltételezve, hogy jelenleg ez a gyakorlat) , hanem horizontálisan skálázol, a hardver pedig egy utility -a devop-os fejlesztőknek-, ahogyaz előadásban is elhangzik. Yaml fájlokkal hozod létre az erőforrásaidat, szerver, adatbázis, load balancer, fix ip , stb.
Árakról annyit, hogy csinálsz 3 clustert, legalapabb computokból , hagyod, rá se nézel, csak úgy van, és a hónap végén kapsz egy kb. 100 $-os számlát. A végén még megérjük, hogy saját on-prem cloud jön a divatba. És akkor senkinek nem lesz igaza...
- A hozzászóláshoz be kell jelentkezni
A végén még megérjük, hogy saját on-prem cloud jön a divatba.
Már most is ez az irány, de ez ott működik jól, ahol több különböző szolgáltatás vagy folyamat alá kell vas, és akkor az ezek közötti rugalmasságot jól kezeli a private cloud. Ha 1 db szolgáltatásom van, akkor a kapacitástervezést nem oldja meg (más szempontok miatt persze jó lehet).
- A hozzászóláshoz be kell jelentkezni