3 ms·
> Physical servers tend to have extreme uptimes, And that might be a bug, not a feature. If you are running on physical servers you’re likely to be overprovis
by znpy 4y ago
> Physical servers tend to have extreme uptimes,
And that might be a bug, not a feature.
If you are running on physical servers you’re likely to be overprovisioning, at least a bit, to be able to absorb peak load.
But most of the time you’re not running at peak load.
If you can scale your workloads up and down, via containers or anything else, you have excess capacity being wasted. Basically you have servers turned on and doing nothing but waste electricity.
In that context you might want to just turn off servers and turn them back on when needed.
And in that context you want servers to boot quickly.
- Alupis 4y agoIn that context, does it not make more sense to rent the infrastructure instead of host in-house? Or, use commodity hardware that does not have all the redundancy and resiliency baked in at the hardware level - after all, it's completely unnecessary for short-lived services. We have solutions for these scenarios already - VM's, Serverless, Containers, etc. I am having a really difficult time understanding the scenario where someone must use a "proper" server with all the long-runtime, redundant, resilient hardware configuration but needs it to turn on and off quickly. Round hole, square peg. There are much better solutions available, starting with commodity hardware and ending with "the cloud".
- JoshTriplett 4y ago> In that context, does it not make more sense to rent the infrastructure instead of host in-house? Yes, but it also makes sense to be able to rent it for short periods of time, billing by the second. And sometimes you do need bare-metal, and a VM won't do.