There are quite a few posts out in the blogosphere comparing Amazon and Rackspace cloud services, as well as others. But many of them are only marginally helpful to organizations that need to decide which provider they’ll use. Here’s why:

Obviously the playing field keeps changing as the providers constantly improve and innovate, so a lot of what’s out there is outdated. But more to the point, these posts by-and-large are not talking about the most important stuff.

Your organization shouldn’t decide which service to use based on opinions about their support or subtleties of their cost structure. You should decide first and foremost based on your application stack and your DevOps mindset. From this perspective the answer is likely to be more straightforward.

I like to organize public cloud providers along a continuum from “chaos cloud” to “datacenter mindset.” At the “chaos” end of the spectrum is AWS and at the “datacenter” end is Rackspace.

AWS is geared toward letting developers quickly and easily spin up and destroy virtual servers. The service encourages you to treat servers as ephemeral, sort of like beef cattle: you don’t name them, you don’t get attached to them and their lifespan is limited. Businesses making the best use of AWS today are highly “cloud aware” and have an advanced DevOps approach. For example, they have achieved some degree of automated fault-tolerance and self-healing virtual systems.

The AWS “chaos cloud” approach is a big mindset shift from the traditional datacenter, where servers are typically long-lived/persistent. In this view, virtual servers are more like pets than cattle: they have names, we lavish attention on them and we want them to stay alive. Many organizations that approach virtual infrastructure this way are just getting started in the cloud and/or need to rationalize a longstanding datacenter approach with the need to automate and accelerate DevOps processes.

Rackspace has its roots in serving the needs of businesses with more of a “legacy” mindset. That said, they’ve made great strides towards addressing the requirements of teams all along the DevOps continuum, and we’re big fans of their accomplishments. For example, many of their newer services support a more ephemeral type of approach to servers, but they still give you “solid hardware” underneath your cloud infrastructure-and why not take advantage of that?

All things being equal, other factors are probably less important in your choice of a public cloud provider than your level of comfort with chaos. So if the way you manage your application stack tends towards persistence, lean towards choosing Rackspace or a similar provider. If your approach is more ephemeral, consider choosing AWS or a comparable alternative.

One final point: As I’ve touched on but haven’t quite explained, where an organization falls on the “chaos comfort continuum” often parallels their “stage of cloud migration and implementation.” We built Bitlancer Strings to help move teams smoothly along that latter continuum, which merits a separate-yet-related discussion. So more on that in a future post. Plus I’ve also got more cattle analogies to throw at you!

UPDATE: Bitlancer Strings is now open source. For more information, visit Strings Documentation on Github.