[mmaunder]

It's open, it's cloud, it's new, it's got NASA involved! So how does this help me move 20 terrabytes of data and a range of web services and customer facing applications from my current cloud provider to a new provider?

The theory is that I can take a data snapshot of my 20 terabytes, move it to the new provider's network by driving it across town (still the fastest way to move data), "drop it in", switch over DNS and excluding a few lost transactions during switch-over everything should work fine.

The reality is that this removes the pain of proprietary configuration from a data center migration but it's still a painful process to switch cloud providers that involves a lot of work, some risk and down-time. So while this is a great marketing play from Rackspace there is still a level of lock-in when you commit to using a provider and so the risk to Rackspace to go 'open' is minimal but the benefits of being the leader are huge.

[wwkeyboard]

I think it's more about the worry that if your chosen provider goes away you have no way to run the service yourself. You would have to rewrite everything using google storage to S3 instead of just migrating data centers.

[bldurling]

Your big problem seems to be moving the 20TB of data. Why not just have the data get copied over to your alternative provider as you create it. That way all you need to do is spin up your images on the alternative provider. You might still lose a few transactions, though maybe having a message queue to handle that on both providers would be a good idea.

[tamarindo]

So you're saying that they are maybe deliberately understating the pain of migrating platforms with this solution simply to achieve recognition as being in a leadership position.

If you are correct, this sounds like quite a cynical move to try to hoodwink potential customers into a false sense of security with an apparent promise of platform independence.