3 ms·

I'm curious what that use-case might be, if you are able to elaborate. Physical servers tend to have extreme uptimes, compared to desktops and even VM's. It's

by Alupis 4y ago

I'm curious what that use-case might be, if you are able to elaborate. Physical servers tend to have extreme uptimes, compared to desktops and even VM's. It's a fairly rare occurrence to need to reboot a physical server (by rare, I mean only when doing updates that require a reboot, such as a kernel update, and these days there are mechanisms to avoid rebooting even under that scenario). Needing to reboot often and be available in seconds just isn't a thing needed by most folks operating physical servers. Typically folks that require that operate VM's instead, which can freely be rebooted without powering down the hardware.

JoshTriplett 4y ago
Many people want to use physical servers via the same kind of infrastructure that gets used for VMs. Consider something comparable to AWS's `.metal` instance types or the Kubernetes "bare metal" provider, for running things that don't run in a VM (such as VMs, since nested virtualization is variously unavailable or slow).
- Alupis 4y ago
  Perhaps I'm just "old-school", but I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. When renting a physical server, typically one understands the trade offs they are making versus operating a pure VM infrastructure, even for development purposes. VM's alleviate concerns about hardware for the most part. Physical servers just are not typically spun up and down in short succession - making the boot time completely irrelevant for all but the most extreme use cases. Many/most of the things a physical server is doing during POST and boot are necessary to guarantee reliability and integrity. Perhaps desktop "off the shelf" hardware is more what should be prescribed under your scenario.
  - JoshTriplett 4y ago
    > I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. Spinning up in response to requests, without having to be constantly running (and being billed for).
    - Alupis 4y ago
      Is this not the perfect (and intended) use case for VM's, Containers, "Serverless" Functions and other mechanisms that all ride on top of already booted physical hardware? It seems to me this particular use case is a lot like wanting a forklift capable of driving highway speeds. Can it be done? Sure. But then you sacrifice a lot of what made a forklift good at it's intended job. There is nothing to be gained from running short-lived code directly on physical servers. Today's Hypervisors are very good at not getting in the way - ie. there is little to zero performance penalty from running a VM, particularly a VM with dedicated resources. In any event - what you desire can already be achieved, just not with your typical IBM/Dell/HP/Whatever server platforms. The things that make these computers desirable (and earn the denotation of a "server") for long-running systems are unnecessary if the goal is to boot, execute some code, shutdown, repeat. Off the shelf commodity "desktop" hardware is fully capable of booting in seconds and executing code - you just lose all the redundancy/reliability - but that's not needed under this scenario anyway.
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 ago
  In 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.

by Alupis 4y ago

JoshTriplett 4y ago

Many people want to use physical servers via the same kind of infrastructure that gets used for VMs. Consider something comparable to AWS's `.metal` instance types or the Kubernetes "bare metal" provider, for running things that don't run in a VM (such as VMs, since nested virtualization is variously unavailable or slow).

Alupis 4y ago
Perhaps I'm just "old-school", but I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. When renting a physical server, typically one understands the trade offs they are making versus operating a pure VM infrastructure, even for development purposes. VM's alleviate concerns about hardware for the most part. Physical servers just are not typically spun up and down in short succession - making the boot time completely irrelevant for all but the most extreme use cases. Many/most of the things a physical server is doing during POST and boot are necessary to guarantee reliability and integrity. Perhaps desktop "off the shelf" hardware is more what should be prescribed under your scenario.
- JoshTriplett 4y ago
  > I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. Spinning up in response to requests, without having to be constantly running (and being billed for).
  - Alupis 4y ago
    Is this not the perfect (and intended) use case for VM's, Containers, "Serverless" Functions and other mechanisms that all ride on top of already booted physical hardware? It seems to me this particular use case is a lot like wanting a forklift capable of driving highway speeds. Can it be done? Sure. But then you sacrifice a lot of what made a forklift good at it's intended job. There is nothing to be gained from running short-lived code directly on physical servers. Today's Hypervisors are very good at not getting in the way - ie. there is little to zero performance penalty from running a VM, particularly a VM with dedicated resources. In any event - what you desire can already be achieved, just not with your typical IBM/Dell/HP/Whatever server platforms. The things that make these computers desirable (and earn the denotation of a "server") for long-running systems are unnecessary if the goal is to boot, execute some code, shutdown, repeat. Off the shelf commodity "desktop" hardware is fully capable of booting in seconds and executing code - you just lose all the redundancy/reliability - but that's not needed under this scenario anyway.

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 ago
In 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.