Update: The Future Path of Rackspace’s Public Cloud Products

A lot has happened since I introduced myself to you here. We’re continuing to listen to our customers and we have accelerated our product releases and geographic coverage in response. Just since January, we’ve launched Cloud in the UK, Cloud Load Balancers, Akamai CDN to all of our Cloud Files customers, new iPhone and iPad apps, Ubuntu on Managed Cloud, higher throughput limits on Cloud Servers, a number of features to our Cloud Files product, and many more. Today, I want to share with you the progress we’re making using open source, namely OpenStack. A significant part of our focus over the remainder of the year will be transitioning our Cloud Server code base to OpenStack Compute, also known as “Nova.” This strategic decision has many implications that will affect the majority of our customers so I want to highlight a few changes.

We will shift our hypervisor to Citrix XenServer from our current Open Source Xen, which we call “Xen Classic.” XenServer is being well-adopted by our customers and partners and is the hypervisor we currently use for our Windows offering. Standardizing on one hypervisor will ensure a smoother transition to OpenStack. We are aware of some functionality differences including the inability to downsize a slice. However, we have thought through this and feel the added benefits of XenServer, including its out-of-the-box capabilities, management features and APIs, outweigh the drawbacks of not being able to size down.

Moving Cloud Servers to the OpenStack Compute (“Nova “) code base
The current strategic goal for Cloud Servers is to fully transition first to XenServer and then to the OpenStack code base.  To get there we will first aim for feature parity between Nova and our current Cloud Servers offering while moving to a common API across our current Cloud Servers offering and Nova.  We will strive to make this process as smooth as possible for our customers as we prepare for the future.

OpenStack’s Cactus release has allowed us to make significant strides in this transition. XenServer support is now a strong part of Nova. Many core public cloud features have been added in Cactus that closes the gap on feature parity. We are approaching the close of final details on an API that can be run on both Nova and Cloud Servers. The progress on all fronts is continuing to accelerate. We feel confident that we can stay on track to deploy Nova to our Rackspace customers later this year.

Another area of focus for Rackspace is a discussion around expanding Nova’s networking capabilities into a robust, flexible network as a service offering. It is exciting to see a large number of industry leaders working together in the open to evolve the thinking around leveraging network services in the Cloud.

Load Balancing
On Tuesday, we announced the general availability of the Cloud Load Balancers service.  While this service was initially developed internally, we are excited about releasing this codebase into the open.  At the OpenStack Design Summit, we will be hosting sessions on the product and technology and begin design discussions around version 1.1 of the service.  Initially, we are proposing this as an affiliated, incubated project of OpenStack. We still have a lot of work to do to make the code more readily deployable and usable for the community, but we’re excited to begin working with the community to develop a ubiquitous load balancing service.

Block Storage
As we look forward to the Diablo release of OpenStack and beyond, we are excited about getting involved in projects outside of just compute and object storage. Block storage is one of those projects and we look forward to sharing our proposal at the upcoming design summit.

Relational Databases
Also at the design summit, Rackspace will be leading sessions to discuss our work and research around relational databases. Work on this effort has been focused on feature development within Nova on the underlying infrastructure control code.  Our engineering leads will discuss how we are approaching this problem and begin engaging the community on a more common approach.  As we’ve started working through this project, it has become apparent that a number of the problems we are solving are widely applicable to other types of products and services users may choose to build in the future.  We want to start a discussion on the best approach to solve these problems and engage the community as we continue developing products and services to build relational databases in the cloud.

And there’s more!
We are offering a proposal and prototype for a common identity service for all OpenStack projects. This is a first step towards supplying the glue that holds OpenStack services together and allows them to interoperate with enterprise IT systems.

Also, we have placed our Cloud Servers API spec in OpenStack for the community to drive it forward. We have proposed an extension mechanism that allows anyone to publish their own extensions to the API in a way that allows for popular extensions to get promoted to native APIs. This mechanism will enable an ecosystem that allows for an open API evolution.

We are moving quickly so check back for updates on these initiatives over the coming weeks and months. If you’re a customer who is affected by any of these activities, we will communicate more details to you directly. And if you’re at the OpenStack Design Summit, look me up – I look forward to meeting you and discussing these initiatives and the future of Cloud products.


  • Ben

    We are aware of some functionality differences including the inability to downsize a slice

    Seriously? Wow, that’s a pretty big deal. Will that functionality be coming back in the future?

  • Thelievense

    I have to agree that the lack of scaling down servers is NOT a small issue but rather a critical FAILURE in your cloud service.

    The whole point of using a cloud service is to both scale UP when a traffic spike occurs, AND the ability to scale back DOWN once that spike is finished.

    The offhanded way that you dismiss this makes me question if you’re really listening to your customers and is indicative of someone who doesn’t use the service day to day driving decisions.

    VERY disappointed to learn not only are you not enabling this functionality on Windows servers but now you’re taking it away from Linux servers too.

    • Pete

      “I have to agree that the lack of scaling down servers is NOT a small issue but rather a critical FAILURE in your cloud service. The whole point of using a cloud service is to both scale UP when a traffic spike occurs, AND the ability to scale back DOWN once that spike is finished.”

      Wait — you’re depending on changing the size (and not quantity) of your instances to scale your application? What if you need to scale up beyond the largest instance available? I’d much rather have four 1GB instances than one 4GB instance when traffic loads begin to spike.

  • Syaman

    If it is true that we will no longer be able to scale down our cloud servers, then I guess it’s time to look for a new provider.

  • Joshua Lund

    It’s extremely discouraging to hear about this switch to a proprietary hypervisor–particularly in the context of all of this rhetoric about OpenStack and moving toward other open components.

  • “However, we have thought through this and feel the added benefits of XenServer, including its out-of-the-box capabilities, management features and APIs, outweigh the drawbacks of not being able to size down.”

    I 100% disagree. This is a very poor decision. One of the key tenants of cloud computing is elasticity. That includes scaling even individual nodes up and down as needed. This is especially true with core services(like DB masters, ANY windows server, and certain KV datastores) that are operationally more difficult to rebuild from scratch.

    With this change you will be forcing people to tear down and rebuild servers in order to scale down instead of just reboot them like you do today.


  • FYI the “higher throughput limits on Cloud Servers” link doesn’t link to the exact fragment in the FAQ and the throughput table in the FAQ still has the old values.

  • Mark Interrante

    Thank you for your comments. Customer feedback, requirements and usage patterns have all played heavily into this decision and we truly feel the benefits of XenServer outweigh the downside of not being able to resize down. There are technical and strategic reasons for this decision, in addition to preparing for OpenStack.

    From a technical perspective, we have heard that customers want more control over their cloud server. XenServer will allow for this through:

    • Customization of storage, OS/Kernel
    o XenServer VHD-based storage allows you to create custom partitioning
    o XenServer allows customers to run their own kernel and to reinstall their OS to meet their particular needs

    • Security
    o VHDs allow you to encrypt an entire file system and XenServer will allow you to run the file system of your choice
    o We are actively preparing for the IPv6 transition including ensuring the best defense against possible attacks. In our opinion, XenServer is better positioned to deal with potential security attacks

    From a strategic standpoint, the ways our customers use our cloud and our ability to support them are key in making decisions. We are now seeing most of our customers scale up (resize up), out (adding servers) and in (deleting servers) instead of sizing down. We view this as a best practice, especially when coupled with our Cloud Load Balancers.

    Getting to one common hypervisor across our Windows and Linux offerings will allow us to provide the very best Fanatical Support experience. New features will come out faster, bug fixes will be addressed sooner and customer support will be better prepared to respond to your needs.

    I appreciate your feedback and hope this provides some context around why we are going in this direction.



    • Dave

      Guys, how is rackspace supposed to meet their financial targets unless they take away the ability to downgrade a “slice”, a term they probably shouldn’t even support any longer

      • Smart Observer

        I love how Rackspace throws XenServer under the bus on the downgrade limitation. Being a sysadmin with xenserver as the foundation I can tell you we upgrade and downgrade constantly within our environment.

        The issue is their TECHNOLOGY MODEL. They use local storage on their servers (had to pry this out of their engineers) so cannot take advantage of a true cloud environment where storage is on a SAN. This would un-bundle processing power from storage. To do this they would have to build a FAST storage network and those are not cheap. So their pricing would adjust considerably.

        Hats off to them how they can still successfully ramp the cloud business with a TON of marketing dollars even though it’s a limiting model. But please Rackspace (if you’re reading this) stop throwing XenServer under the bus.

  • same here

    I feel the same way, if there is no more downsize, I’m going to Linode.