Post History

Well - all these examples essentially are ways to spread out utilisation of "work" between PCs.

To start with - "Cloud" servers essentially *are* VMs, running on managed hardware. While in many cases the 'details' are abstracted away from developers, they run many of the same OSes and systems that a 'real' server might. 

> Say you have some services that are busy during the day and others that are busy at night. You need 50 computers to do each of those things. You can now do both with 50 computers by giving priority to VMs based on time of day.

You might not want to run them on the 'same' servers - either for security or redundancy reasons. This sounds a 'lot' like VDIs - in which case you're running "PCs" centrally and using less powerful clients to access them.In this case you can 'manage' your systems in one place - with updates and maintenance done on the virtual machines, and redeploy resources as needed. 

You could also in theory turn *off* VMs not in use, and get them up faster than bare metal. 

> 2.1. This sounds like uploading the mission-critical services to a cloud server? Then why do you need VMs? What if the VMs are on the computer that had crashed?

In most 'practical' VM setups, you'd separate out storage, management and your virtual machine host. Essentially what happens if a server crashes is your VM management 'node' realises its down, and starts up a new copy of the VM, using the shared storage on another system and that takes over. You might also have extra copies of storage for redundancy and backups. 

While in theory you *could* run physical machines similarly - you'd be running hot and cold spares (A machine running with the services, or a machine with the services installed ready to take over) - you'd have them sitting around doing nothing 

> 3.1. If your "tiny apps" "don't really need much power at all", then how can you save money on hardware? Why do you need "independent VMs"?

Lets say I want to run multiple services that I want to expose on port 80. Only one application can listen to a port on one server. With a VM setup, I could have one VM sitting in front talking to the outside world, routing data to the respective, correct services each running on a self contained VM or container. I could also restart *one* service, and its associated dependencies, and it would not affect unrelated services.