Jsem tady jediny, komu ten clanek prijde sepsany dost tendencne?? Ten clovek porovnava hrusky s jablkama, velkou cast jejich spendu tvorili PaaS sluzby, takze srovnavat to s cenou HW v onpremu uplne nedava smysl. PaaS sluzba se supportem, ktera nema za smysl byt levna, ale sejmout ze zakaznika urcitou cast jejich prace, za kterou plati providerovi. Smysl by davalo spocitat to proti EC2 treba s balancery na kterych bezi stejne technologie, ktere provozuji v DC.
To same plati o clanku, ktery ten pan sepsal k lambdam, jasne ze plati, ze lambda, pokud ji utilizuju 24 hodin denne je draha, ale to preci neni jeji usecase, pouziju ji tam, kde potrebuju narazove spousteni nejakeho kodu. Navic kolik zakazniku svym workloadem utilizuje HW na 100%(pokud pominu fakt, ze HW na 100% realne provozovat nejde) 24 hodin denne??
Rozhodne si troufnu tvrdit, ze zpusob vyuziti cloudu jaky ten pan popisuje neplati pro vetsinu zakazniku v CR.
Jinak tema ceny u public provideru je tema, ktere me hodne zajima, takze pokud mate nejake realne pripady, kdy byl cloud presneji AWS drazsi nez onprem budu rad kdyz mi je hodite do mailu.
Diky vsem.
Lukas
Prijde, dokonce si myslim, ze kdyz odchod byl tak jendnoduchy a v textu jsem.nekde videl ze nepremysleli o vyuzivani saas, tak jsem nabyl nazoru, ze implementovali onprem logilu na cloud. Tym rozsirovat ani menit nemusel, jinymy slovy, udelame migraci z onprem do cloudu a budem tam dal pouizivat ten bambilion virtualek.
V cloudu delam jiz delsi dobu, predtim jsem byl server admin. Neda se to srovnavat s provozovanim saas.
Je smutne kolik firem a lidi ai mysli, ze prenesou virtualky do cloudu a zaskrtnou si cloud fajfku :D. Ale neprekvapuje me to.
Tohle tvrzeni je trochu vystrel do prazdna, pokud nevime, jak jste vypocet delali. Spousta lidi ma tendenci porovnavat cloud proti nakupu HW a zapominaji, ze nakupem HW to pouze zacina. Potrebujete zaplatit datacentrum, elektriku na napajeni,chlazeni, vybaveni DC atd. Pokud clovek na tohle vsechno zapomene, pak to nemuze nikdy vyjit.
Pouzivali jste pro vypocet tooly, ktere naskanuji Vase prostredi a rovnou navrhnou optimalizaci jednotlivych VM?? Nebo jste to sizovali 1:1??
Mám na jednom projektu dva servery, jejichž pořizovací cena byla dohromady cca 220k Kč. Oba 256 GB RAM, 32 jaderný EPYC a 4x2 TB NVMe v RAID 10. Housing v DC stojí cca 6k. Servery rozpočítané na dva roky vychází na 9.2k měsíčně. Když se budu hodně snažit, tak EC2 instanci, která zastoupí jeden takový server, budu mít za $1300 měsíčně, tedy cca 30k Kč. Za dva servery 60k Kč a to ani nepočítám trafik, který by vycházel na stovky dolarů. V tomhle případě je ten rozdíl úplně absurdní. Jak člověk má nějaký významnější baseload a nedejbože provozuje třeba větší databázi, tak cenově cloud nemůže konkurovat ani vlastnímu ani pronajatému HW.
Ten server ale není vytížený 24/7, že ne?
Dokud k tomu budeš přistupovat tak, že potřebuješ velký server, protože škáluješ jen vertikálně, cloud se ti asi nevyplatí.
V cloudu se dá ušetřit, když potřebuji výkon nárazově, když umím workload škálovat horizontálně, když umíš svoji aplikaci přizpůsobit.
U jednoho klienta ve finančním sektoru jsme měli cluster podobně nadupanách serverů s sql databází, smysl byl jediný, sloužil jako backend pro power BI na generování reportů. Ten projekt nám byl uveden tak, že nelze ušetřit, že se data počítají kontinuálně a je nutné je mít co nejdřív napočítané. Když jsme se do toho zanořili, zjistili jsme, že se počítají kontinuálně jen proto, že exporty z různých core systémů tam jedou náhodně v dlouhé smyčce a že 90 % vstupních dat jsou vlastně denní snapshoty. Dnes se hlavní data počítají 4x denně, na to se spustí instance v cloudu, data jsou uložena v parquet souborech na ADLS a power bi na ně přistupuje přímo, těch pár rychlích dat se tam nahrává každých 15 minut. Úspora je neuvěřitelná, i s 30 TB historických dat za 10 let se vejdeme měsíčně do 200 EUR a přitom response time v power bi je výrazně nižší, reportů je dnes už přes deset tisíc a přistupuje k tomu stovky uživatelů.
Takže ono to vlastně záleží. Podobnou úsporu by šlo ale udělat i na vlastní HW, výhoda cloudu je schopnost dělat rychlé iterace, experimentovat. Při nákupu HW to je těžké rozhodnutí na roky dopředu, ty nakoupené servery se prostě špatně upgradují a nikomu se do toho nechce.
Load se u obou pohybuje mezi 10 a 15 a RAM je využita na jednom téměř ze 100 % a na druhém 80 %. Úplně v pohodě můžu škálovat horizontálně, teď kupuju další dva stroje. Prakticky stejné s dvojnásobnou RAMkou a disky.
Vtip je v tom, že vlastní HW je tak levný, že tu konfiguraci můžu napálit klidně 10x a v horizontu pěti let to vyjde líp jak cloud s tím, že mám úplně masivní rezervu a vím, že nezaplatím nic navíc. V takovém Frigate nebo v Lambdě, když udělám chybu, tak lítají komínem tisíce dolarů.
Servery se upgradují tak dobře, jak dobrou mám infrastrukturu. Stejný problém je v tom cloudu, pokud si infrastrukturu navrhnu špatně, tak EC2 instanci bez výpadku neupgraduji.
Ten příklad s reportem je docela extrém. Většina workloadů musí odpovídat na requesty pořád a neběží půl hodiny denně. Ale i tak .. před lety jsem byl v projektu, který počítal co je potřeba objednat do skladu, aby v něm nebylo moc mrtvého zboží. Ten výpočet trval 8h a pracoval s desítkami GB až jednotkami TB dat. V cloudu to vycházelo na nesmysl. Navíc vývoj takového řešení je docela bolest v úvodní fázi, kdy se to musí testovat ale i během provozu, kdy se ten software iteruje. Vývojáři to potřebovali pouštět celé pořád dokola.