As a Solutions Architect within Rackspace’s Big Cloud team, I have the good fortune of working with both private cloud and public cloud customers. I often see businesses adopt hybrid cloud strategies, whereby services consumed span both these platforms. Deciding where to put different workloads ultimately begs the question: how do public and private cloud platforms stack up against each other from a performance perspective?
Let’s start off with a basic understanding of the key concepts that apply to both environments.
Your instance (or virtual machine): In the world of public cloud, your instance will share a physical host with other customers’ instances (unless your instance is large enough to consume the entire host). Within private cloud, you own the physical hardware and therefore do not share hosts with others. Naturally, the performance of your instances (on either platform) is bound by the constraints of the physical hosts upon which they reside, so you should be aware of capabilities when deciding on where to put workloads.
The exact specifications of the host servers running public clouds are not typically listed. This is for good reason – as providers may (and usually do) utilize different host machines across a cloud platform. So we are instead provided with the relevant instance size (based on RAM, vCPUs, storage and throughput). For more information on Rackspace Public Cloud instances, check out: http://www.rackspace.com/cloud/servers/techdetails/
From the above link, the most abstract number you’ll see is the CPU, which is quantified by the number of virtual cores (as opposed to any measurement of physical cores or clock speed). The majority of our host servers run AMD Opteron dual quad-cores at 2.2GHz to 2.4Ghz. Currently, and this will change in future, a 30GB instance consumes an entire host machine. The 8 vCPUs presented to your 30GB instance consume all 8 cores across the physical processors. Smaller instances will get proportionally less CPU. This provides a reasonable expectation of CPU performance.
An equally large consideration here is that the public cloud can be less predictable in terms of disk performance (or IOPS) because of the “noisy neighbor” effect. This implies that you can be affected based on usage by other customers on the same host. The same rings true for private cloud, but as the hosts are dedicated to one customer only, you have greater control and awareness over instance and role distribution.
Test performance: When running workloads on both a private and a public cloud, it’s advisable to test the performance of your application on both platforms. This will provide you with data that you could turn into a useful performance ratio; for example, if one compute unit in private cloud provides the equivalent of 1.7 compute units in public cloud, you will quickly work out where workloads are going to be most cost-effective dependent on the duration of the project and your burst requirements.
Typically, private cloud will provide better bang for buck for your consistent 24×7 workloads (assuming you have more than a couple of hypervisors), whereas public cloud’s attractive per hour billing model will suit temporary workloads, seasonal or spiky traffic.
An understanding of these concepts should provide the guidance necessary to start deciding where workloads are best suited. You can easily consume both Rackspace Private and Public Cloud; and because both are based on OpenStack, the platform and API experience is consistent.