There is likely a point of diminishing returns in this type of scenario. The OS boot time, the web service setup time, the actual request and then the shutdown time. Also consider that unless you have an external caching layer, you may be processing some requests that could have been cached by an always-on server. If your site has predictable traffic patterns then I suspect the math would be in favor of always-on provisioned servers with scale up/down based on traffic. If you have a very high traffic site the extra OS boot time (even in milliseconds) is going to add up quickly. You'd have to be very sure the spin up/down time is less than the idle time of the always-on server.

>It is now possible, technically anyway, for operating systems to boot, service the request and disappear.

This was already possible even with a 2 second boot time. The problem is that it's a stupid use case because (unless the OS boots up in <10ms) the latency of waiting for the bootup is intolerable in any use case where a 2 second boot time was intolerable.

If you're doing that, why bother loading an entire operating system? Just use something like AWS lambda instead.

And that's great. But it's meaningless when the base-cost per unit of computation capacity is so high that it is in most cases cheaper to have a whole farm of servers running idle elsewhere.

Isn't that what lambda is all about? Sub-second billing?