Would be interesting to hear from either Richard or Chris does it add value to be able to declare vertical scaling rules a priori as well as having the ability to change parameters at runtime - another valuable piece of functionality in any IaaS interface.
Short answer - fixed parameters are generally sufficient in an IaaS API: - For a single server, different technical aspects have very different scaling behaviours. With typical operating systems many of these changes (mem, cpu, disk) require a reboot, so there is no gain in defining scaling rules for those rather than having the user specify the new parameters when they reboot. Network is the exception, but is complex enough that I think we're looking at vendor extensions here. - For multiple servers, there is scope to define scaling rules for all dimensions in terms of when additional server instances should be added. However, this is typically done above the IaaS API by management software such as RightScale.
For a machine: - Set memory utilisation to 512MB but allow to grow to 1GB if demand exceeds minimum capacity
Very hard to implement with typical virtualization platforms and operating systems - e.g. Windows would require a reboot to notice that additional physical RAM is available. In theory this could be implemented on a running server with something like the KVM / VMware ESX balloon driver. In practise ElasticHosts and others do not do this - users reboot their servers to change their total RAM.
- Set number of CPUs to 2 but allow to grow to 4 if demand exceeds minimum capacity
Even harder to implement. I can't think of a common server OS which supports changing the number of CPU cores at runtime without a reboot. However, changing the priority of the virtual machine versus others on the same virtualization host is practical whilst it is running, without any modification or reboot of the contained OS.
- Set disk space to 5GB but allow to grow to 10GB if demand exceeds minimum capacity
This would make sense if storage were provided in terms of a quota for files, however we (and most other IaaS) provide "disks" - a block device which the customer partitions and formats. Here again, an increase in storage means repartitioning and hence typically a reboot.
- Set network bandwidth to 10GB/s but allow to grow to 20GB/s if demand exceeds minimum capacity
This is the case in which vertical scaling rules are useful - if a customer has bought a 10Mbps pipe with 50GB of transfer then what should happen when their website is slashdotted? ElasticHosts current algorithm is to always give all customers the maximum available burst capacity (typically 100Mbps shared pipe), but to email customers and then cut their link when they exceed their prepaid transfer quota. This isn't ideal, and I can easily imagine customers wanting to specify more complicated rules (e.g. email when they hit 90% of transfer quota, then throttle bandwidth for last 10%). Unfortunately the range of possible policies is so great that I think we'll looking at vendor extensions rather than the core API here. Cheers, Richard.