This is a slam on virtualization, not Ruby/Rails. Bad title, but the overall point remains: When you buy a "slice" of something, you have no idea what you are really buying. If you buy a piece of hardware with 32GB of RAM, then that's what you get. And if you know what you are doing, it is going to be much cheaper than buying "slices." In other words, the whole pizza is always cheaper than if you were to pay for 8 separate slices.
Most virtualized infrastructure providers give you some guarantee of how much RAM, CPU, and diskspace you will have available. You may be able to exceed the limits from time to time, but the minimums should be clear when you sign up.
that's not the point; the point is that if you buy 32 1GiB 'slices' even if you are getting completely fair slices that really have 1GiB ram, they are going to cost more than buying one server with 32GiB ram. (now in some situations, 32 1GiB slices are going to be more useful, but 1 32GiB server is going to be cheaper than 32 1GiB slices. )
I sell slices myself; and this is something that should be clear to everyone; the reason why you'd want to buy a slice from me (or someone else) is that a 1GiB slice from me is a lot cheaper than a dedicated server with 1GiB ram.
now, some VPS providers have really cool provisioning systems that add a lot of value (I'm still working on mine... but I'm not there.) but those are not unique to virtualization. You can build really cool provisioning systems to work with hardware servers as well. The win from virtualization is that 8 cores/32GiB ram is the most economical server configuration at the moment; with virtualization you can slice that up into smaller servers for people who need less than 32GiB ram /8 cores, and save them a bunch of money.
Probably because it would be impossible without having a dedicated physical disk for each slice on the machine, or some kind of really fancy network storage array.
Maybe that will change once SSDs become the default hardware. Without the bottleneck of seek time, latency should be much easier to quantify. Also, since you wouldn't be penalized for "context switching" (I know this term doesn't really apply to disk IO, but I mean switching disk jobs often, which requires a head move on HDs) you could maybe someday slice up the SSD time like a CPU and guarantee it directly. (For instance, if the SSD is capable of 200mbps, you're slice could be guaranteed 10mbps. Or something more technically realistic, I am but an amateur.)
