13 ms·

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 phy

by 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.

by Alupis 4y ago

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.