Well simply put it means that you can have Rightscale create the VM image for you in a way that means you can deploy it to pretty much any cloud you want. This means you can start doing SLA/price arbitrage across providers and reduce any potential lock-in from the cloud provider. I like to think of this as an "iPhone strategy" as before the iPhone it was the carrier who would specify what the phones did and would put network specific cruft on them. Apple came along with the iPhone and said "nope, our phone, exactly the same, every network, managed by us", Rightscale is effectively the iPhone and iTunes for your cloud provisioning. By using an intermediary approach you get to control not just the standard stuff like number of VMs, CPUs, Storage etc but the more important stuff like which actual cloud you are deploying to. If you want to shift it in-house from an external provider then you can, if you want to shift between providers then you can, and if you want to start off internally and shift it externally when demand spikes or when it makes financial or security sense then you can.
So Rightscale are doing to clouds what clouds have done for tin... commoditising them. This means cloud providers are in a volume business with retail style metrics and margins. Effectively this means that Rightscale are achieving commercially what Open Cloud has so far failed to do publicly.
So in the same way as you wouldn't consider an Intel/AMD box where your software could only ever run on Dell (for example) why choose an approach to clouds that means you can only choose one provider?
Oh and I bought the drinks BTW.
Technorati Tags: SOA, Service Architecture
3 comments:
Two of the many reasons why things aren't that simple:
- "data gravity" (see http://blog.mccrory.me/2010/12/07/data-gravity-in-the-clouds/)
- platform services. I touch on that one a bit (though more in a PaaS context), at http://stage.vambenepe.com/archives/1440 . The idea is that people often don't just use Cloud providers as "VMs on demand". They use complementary services (Amazon makes a new one available every other week, the latest one being their email delivery service). And these don't port as easily as porting VM images.
William,
I think you are right that its not operationally trivial, and I've talked about the data volume challenge myself before.
On the later point if you engineer your solution for a specific cloud provider then it certainly locks you in more. What I was referring to however was more the cost and challenge of moving "vanilla" x86 applications rather than the cost of moving cloud specific engineering. While some companies are looking at cloud specific apps, lots are today just looking at using VMWare or AWS as an x86 wrapper and considering storage in a similar way to non-virtualised environments.
Its for this group that I think that Rightscale is a no-brainer. This doesn't mean that the total cost of migration is zero just that migration is possible which has its advantages.
In the JEE world, if you have a vanilla application which is written to the specs and uses minimal vendor specific extensions then you have an opportunity to move. Quite often having this opportunity enables you to negotiate cheaper pricing as the vendor knows that if you get too much pain you could, theoretically, jump. The reality is that jumping is still painful and work needs to be done but its the potential to move that keeps the vendor honest.
Its this that I think Rightscale brings to cloud arbitrage. Sure you might have 2 TB of data which will be a bitch to move to a new provider, but it won't be impossible, this means that you can have a "demo" solution up on a competing cloud in a short period of time and use that as leverage in my price renegotiations or use the cost of shifting the 2 TB as leverage against the new supplier.
People signing up to PaaS are being a little dangerous IMO as its effectively like signing up to z/OS with IBM. You are locked in unless (as with Amazon's latest offer) the PaaS solution uses a standards based container where you could shift the app reasonably simply elsewhere.
The reason why cloud suppliers want to get into PaaS is that it significantly increases lock-in and this is exactly the reason why large enterprises should probably avoid it.
Steve,
OK, I understand the point. I just think sticking to "VMs on demand" and meeting every need (e.g. load balancing) via an appliance rather than a native Cloud service is going to be very limiting for customers.
But you're right that as soon as you step out of this (and as long as there is no interop standard beyond x86), you weaken your negotiating position for the benefit of vendors.
Post a Comment