Re:V100 Server On-Prem vs. AWS P3 Instance Cost Comparison
by icelancer on Tuesday February 19, 2019 @01:47AM
(#19197129)
> People often think they have workloads like that.
This is exactly what I see on the regular. The AWS model promises huge savings if you have these cyclical use cases and rarely does this ever happen in a small business or startup.
Re:V100 Server On-Prem vs. AWS P3 Instance Cost Comparison
by devonkim on Tuesday February 19, 2019 @09:23AM
(#19199074)
Worse, you can have such needs but wind up overprovisioning because your software is tough to autoscale automatically up or down. In that case you should probably pay for dedicated, mostly static servers in traditional setups until you can’t stomach the costs of being overprovisioned anymore then go to a cloud that lets you autoscale to recover a lot of your costs. Sure, reserved instances help substantially but because it’s a cloud instances themselves can go up or down without the best SLAs (I still say I’ve had more physical servers among the tens of thousands seen go belly up than the hundreds of thousands of EC2 instances I’ve seen in my experience).
Other factors are obviously the ability to get a compute instance up immediately or because you have bad operational situations (horrible legacy DC equipment, genuinely bad admins or vendors, etc) that far outweigh the opex and capex parts of the equation and bleed into SLA, poor reputation / relationships, etc.
People often think they have workloads like that. I've done work on plenty of setups over the years were people were certain they had lots of big spikes, but most of them only had moderate day/night cycles (and usually a lot less spiky than they thought, because they'd never bothered to measure).
Only in a few cases I've seen usage patterns that justified spinning instances up/down very often, and for those cases, ironically the availability of clouds have made dedicated hosting more cost effective, because if you host everything in VMs or containers anyway, you can now get to far higher utilization levels on your on-prem/colocated setups, and be prepared to spin up some cloud instances (automatically, if you wish, it's not that much effort), and tie them into your cluster when your load warrants it. It's not suitable for all workloads, but it works surprisingly well if anything.
I do see that argument a lot for using cloud providers, but the vast majority of cloud setups I've seen end up having very static workloads growing at rates that gives plenty of time to prepare.