Nuclear Rooster

Why Rackspace should (actively) play nice with Config Automation

Rackspace Cloud is a popular, growing public cloud provider. From their traditional
high-touch dedicated server hosting, to their Slicehost acquisition, to their OpenStack
initiatives and support, Rackspace is no stranger to running an managing servers. Yet,
the Rackspace Cloud leaves a lot to be desired when creating production-ready systems
deployments.

On the spectrum of cloud offerings, Rackspace is more of a dense low-hanging San Francisco
fog than a whispy sirrus-stratus cloud formation: the Rackspace Cloud is very approachable
to those coming from tradition server infrastructure, but it lacks many of the features
essential to a true cloud-based deployment of non-trivial system infrastructre.

One example of this is Rackspace Cloud's faculties for interacting with Configuration
Management tools like Chef, Puppet, and CFEngine. Declarative configuration management
is an essential part of large-scale deployments, wherein your systems rely on introspection
and interaction, attempting to achieve the desired configuration state (even if they
have to try a few times to overcome intermittant network outages or other issues).

One thing tools like Chef help with is to abstract away some of the differences between
different cloud providers, public or private. Rackspace cloud, for example, offers
both a public and private network interface whereas Amazon's EC2 offers only a private
interface along with a DNS name that routes to the private interface. Without a tool
to abstract these differences, it is painful to manage systems that span multiple cloud
providers ('cloud agnostic' or 'hybrid cloud' setups).

In order to acheive these abstractions, Chef probes the server and network to determine
which cloud provider is hosting the system. EC2 'plays nice' with Chef, making it easy
to indentify an EC2 server accuratly, tested over hundreds of thousands of server launches.
Rackspace Cloud, does not make things quite so easy, and tools like Chef have to 'guess' and
do not always have enough information to guess correctly, which cracks the cloud-provider
abstractions and can prevent Chef from working at all.

It is 100% in Rackspace's interest to work with the Chef maintainers to define a better
way to deterministically identify Rackspace Cloud servers. For one thing, anybody using
Chef is likely launching many servers, and more servers means more money. And while
Rackspace is probably pulling in some significant dough with their cloud services, they
have some negative brand associations created by their high-touch, support-driven
hierarchies. In my mind, following up directly on THIS TICKET or elsewhere would speak volumes,
indicating that they are actually interesting in providing services for next-generations
application and platform deployments, not just bringing buzzword-compliant virtualization
to clients who can't afford dedicated hardware.

Rackspace is a major player in the public cloud arena, and thousands of customers run
thousands of servers on their platform. However, if Rackspace doesn't address the client-base
that is trying to push the limits of cloud deployments, they will lose customers and thought-leadership
in the long run.