Quote from: btcmind on September 11, 2013, 06:11:53 PM

Monitoring service levels of machines is very hard. Perhaps I'm misunderstanding something.

When you abstract away the difficulty of replicating the VMs, I think monitoring becomes trivial:

* Each VM has a base OS on the main volume that is "instantly" cloneable
* A secondary user volume is created, formatted, and mounted at ~/.bitcoind/
* Necessary user configuration copied into place including up-to-date blockchain data files copied from internal datastore
* bitcoind is started and is set to start on boot
* RESTful layer is started and set to start on boot
* VM is available for SSH authenticated by user key pair

End state is that a virtual machine can be spun up within a few minutes. Given the components above, it'd be trivial to move the user partition to a new instance if the first dies or needs to be killed. Monitoring metrics would have to be put in place to determine when a machine is killed/etc., but it's not an insurmountable task. And it's something that the theoretical service would be responsible for, obviously.

This is obviously in much more technical detail than I expect the average developer will want/need to know, but I'm hoping it makes things more clear. In the end, the daemon itself doesn't matter much. If you wanted some custom build of bitcoind to work in the same way, it'd be possible, but the workflow would be a little different.

Better? Worse? Happy to hear from anyone else that has an opinion!