Ezt szerintem máshogy is lehet nézni. Amikor számítási kapacitást nézel, akkor így is úgyis VCPU-ban számolsz, ha saját szoftvert futtatsz akkor annak RAM kell.
Nem, akkor megnézed pricing, hogy mennyibe kerül adott kapacitás, és nem érdekel, hogy a SaaS szolgáltató azt öt vagy száz géppel oldja meg. Amikor veszel például email szolgáltatást, akkor nem érdekel, hogy a Microsoft azt hány géppel szolgálja ki, nem érdekel, hogy milyen szoftvert használ, te kapsz egy UI-t, API-t, egyebet, amivel használod. Ha jön az, hogy "én saját szoftvert futtatok" és vCPU meg RAM és storage a számolás alapja, akkor nem az Amazon/Microsoft/Google a legjobb választás. Adnak ők ilyet is, csak aztán vastag lesz a ceruza a számlán.
Managed kubernetes esetén ezeket ígyis úgyis ki kell fizetned.
Ott is az van, hogy akkor kell felhő, ha nem tervezhető a workload, vagy tervezhető, de az idő nagy részében nincs terhelve. Ha ott fut valami saját szar konstans, n darab node-on, akkor újra ott vagyunk, hogy a cég balfasz, jobban jár on-prem vagy bérelt bare metal szerverrel.
Ráadásul az a helyzet, hogy minél absztraktabb SaaS service-t veszel igénybe, fajlagosan annál többe fog kerülni egységnyi erőforrás.
Nem, ez fordítva szokott lenni. Minél inkább SaaS-t veszel igénybe, annál olcsóbb. Minél inkább n darab vasban gondolkodsz, annál drágább.
Mondjuk amikor a saját szoftvered futtatásához kell 500 VCPU meg 1TiB RAM, akkor az fog kijönni, hogy ezt AWS-en futtatva annál olcsóbb minél kevesebb managed service-t veszel igénybe.
Konstans kell 500 vCPU és 1 TiB RAM? Akkor ez nem felhőbe való. Ha kell max 500 vCPU meg 1 TiB RAM, de mondjuk egy évre átlagolva kell 50 vCPU és 100 GiB RAM, akkor felhőbe való, mert kurva sokat lehet spórolni azon, hogy nem veszed meg a 10x akkor vasat, mint amennyi kell belőle. Nagyon sok cégnél nem értik a felhős dolgot, az Amazon/Microsoft/Google pedig dörzsöli a kezét, ahogy ezeket a balfaszokat megkopasztja.