This blog is a space for my thoughts, ideas, concept development, observed oddities exploration but mainly for much needed RANTING space from a frustrated penguin against the powers that be. Long live the yellow beak!
IAAS CPU bursts – Can it be bad?
Rackspace, in its cloud servers service, generously gives hosted machines unallocated CPU cycles, above the guaranteed levels (reference). In a study I’m conducting these days, comparing performance of the biggest IAAS providers, this innocent feature revealed itself very clearly. Comparing the smallest instances of both EC2 and Rackspace CPU benchmarks, and normalizing to benchmark points per one cent, I discovered that the Rackspace offering is better by more than 3500%!!! Even if the two 2G memory instances from EC2 and Rackspace are compared, the difference is still more than 430% in RackSapce favor. It’s important to note that these numbers do not carry to the largest packages where the difference is about 380% in EC2 favor.
My benchmarks also revealed that there is no real difference in the CPU benchmark scores through all of Rackspace instance packages, while EC2 and GoGrid scaled more reasonably. My eyebrow went up at this point.
Here is a reasonable assumption that can explain these strange findings. Buying Slicehost proves that Rackspace want in on the Cloud hype. They want in, and they want to do it fast, being a relatively late comer. A lot of servers were probably allocated to this project. Prices go down very fast with large numbers. It’s safe to assume that these servers are mostly undeployed for the time being, waiting for the hordes of clients to come and host their servers at Rackspace. Along these lines, it’s a safe bet that Rackspace CPU benchmark numbers will go down eventually, and equlize with all the other IAAS providers.
For some, this might sound like a dream come true. If CPU bound transient resources is the requirement, Rackspace is the place to host these jobs, for now at least. If you plan to jump on that moving wagon, don’t do any long terms planning on the numbers you get. On the other hand, building a system for the long term on infrastructure that includes resources that will one day simply disapear is unsound. It can still be done, but special care should be put on the ongoing changes in service.
