Some time ago the inimitable Dave McCrory postulated a theory on Data Gravity in the Clouds (which I agree with wholeheartedly). I then applied the concept of gravity to converged infrastructure but in this case I showed that applications and services experience gravity but did not mention data (on purpose).
Alex Williams then wrote a post on Silicon Angle to ask the question (my interpretation, sorry Alex!): Does Data Gravity apply to Vblock? is it possible to join up cloud gravity with converged infrastructure gravity, perhaps unify the theory across public clouds and converged infrastructure?
First, a story:
Once upon a time I worked with the Chief Architect of a global financial institution to convince him that converged infrastructure was the new metric unit of IT that he could use to compose services faster, to a higher quality, compliant with standards, with more efficient ops, and it looks sexy too, if you like that kind of thing.
His response was: well, this all sounds fab and groovy but it won’t work if YOU don’t help me with two things:
1. You need to help me migrate applications and their data from the museum pieces onto your new shiny unit of IT.
2. When your new shiny unit of IT is no longer new and shiny, say in five years time, then you need to help me migrate my applications and their data from your museum piece to the future shiny units of IT.
Essentially he was asking for anti-gravity methods prior- and post-Vblock. I’m going to focus on request number two because that’s related to Alex’s question: if data gravity applies to a Vblock, will this prevent moving “off” a Vblock? In simple terms: if data gravity applies to a Vblock, does it “lock you in” to the platform?
We know that Converged infrastructure has its own network, compute and storage. In a Vblock VCE’s goal is to balance the architecture so you benefit from “Wire Once and Walk Away”: the cost, complexity and risk of having to refit infrastructure in your datacenter once the kit is live is too high. One of the design decisions that defined the Vblock standards is the concept of each Vblock owning its own storage rather than accessing a (fragile?) SAN or some other unknown and unbounded storage system external to the Vblock. This doesn’t mean that the data on that storage is permanently stuck to that Vblock though.
In the case of data movement, a Vblock allows many ways to move data in and out of a Vblock in the form of data anti-gravity methods:
- Backup – whether you want to do it over ethernet or fibre-channel, the Vblock is ready (ports allocated but left free, for example) for backup (moving data off the Vblock).
- Migration – a common method of migrating data on and off a Vblock is to connect it’s ethernet and fibre channel to specific, existing networks to use VMware tools (vMotion and svMotion, for example) to motion applications and their data to and from a Vblock.
- Replication – Vblocks make this real easy using EMC’s RecoverPoint.
- Federation – make two (or more!) Vblocks look like one (from the view of the application) using Cisco’s OTV and EMC’s VPLEX.
- Access – you can access the storage inside a Vblock from a compute unit outside using ethernet or fibre-channel protocols.
So do these five ways to move data on-and-off a Vblock mean that there is no Data Gravity? Note that each of the above has a measure of complexity, risk and cost. Now you need to read another of Dave McCrory’s posts on Artificial Data Gravity.
Reading all that I think there are two key factors that give the answer, Yes, Data Gravity does apply to Converged Infrastructure:
- Design – The Vblock standards that are enshrined in the architecture and the manufacturing processes stick data to a Vblock.
- Cost – The cost of the anti-gravity methods means that, even if they make it possible to migrate data on/off, it means there’s a cost nevertheless.
So there you have it, Dave and Alex were right, data gravity does apply to a Vblock, despite the anti-gravity methods, and we do have a grand unified theory (unified as in applies to the public and private infrastructures).
