vSAN vs. ScaleIO – fight!

[updated July 25th, 2013, 2:00pm ET – edits/corrections]

I guess I’m not immune to the temptation for the inflammatory blog post title :-)

Over the last week, I’ve gotten a lot of “vSAN and ScaleIO seem similar – I don’t get it why would EMC/VMware do the same thing, can you help clarify?” questions from customers, EMCers and our partners.   Let me try to clarify.

First things first – you need to understand something very much built in to the EMC worldview that starts with Joe.  Here’s the Joe Tucci view:

“Yes, we have overlap by design.  It eliminates seams that our competitors can drive through.  We run multiple bets down a path by design to see what sticks/holds.  The challenge for us is to always consider first the customer and the requirements and focus on the ‘right’ solution on a campaign by campaign basis.” – Joe Tucci

Across the “Federation” of the 3 independent (but strategically aligned) entities of VMware, EMC, and Pivotal – it also means that customers have complete open choice – with each of the parties operating in a way that enables choice.  The choice of choosing VMware but not EMC; or Pivotal Cloud Fabric or Pivotal HD (the Pivotal distributions of Cloud Foundry and Hadoop respectively) and running it on AWS or vCHS, or whatever.   (BTW – on this note, look at the Cloud Foundry Pivotal/IBM announcement from today as an example of the upside of that model)

For the MOST PART customer tell us they dig this.   I think we can always do more to work together better.  

OK – now look at the vSAN/ScaleIO through that lens:

• First – at the top level of “what are they”, yes – vSAN and ScaleIO are similar.  They are both distributed transactional software stacks, and ones that are “software only, bring your own hardware” models.   They share many architectural models (internal “object” mechanics with replicated content for failure handling, read/write caching layer for localization of data using flash, a “client and server” layer in their stacks, distributed metadata internals)
• Like many EMC/VMware actions – when we see a customer need (in this case "I want a 'software only transactional stack'") we: SIMULTANEOUSLY attack it from:
• Perspective 1:  "Start by assuming you're using vSphere" viewpoint (led by VMware – still open of course – but VMware-centric, sometimes using some EMC intellectual property like Avamar in VDP or several other examples)
• Perspective 2: "Start by assuming you’re using VMware, as well as several different hypervisors + physical environments, each with 'a bunch of different workloads'" (led by EMC – still open of course – but EMC-centric, sometimes using some VMware intellectual property).
• vSAN is focused on “Perspective 1” aka from the view point of start by assuming VMware:
• It's designed to be "invisible" when you're using vSphere
• It's deeply embedded in the VMkernel (so it’s harder to expose for external use but conversely vmkernel embedded gives some advantages)
• It's management model is "you manage it via vCenter".  See above.
• It's designed for vSphere cluster “levels of scale” (in currently shipping vSphere 5.x releases – this maximum is 32 nodes)
• Scale IO is focused on on “Perspective 2” aka from the view point by assuming "all hypervisor/physical hosts"
• It's designed to "run on" heterogenous infrastructure – and isn't invisible (it has it's own management model)
• It's mostly OS agnostic (including running as a virtual machine for hypervisors).   It's dependent on a OS level driver (for both client and server functions)
• You manage it via the Scale IO management tools.
• It's designed for "cloud scale" (tens to tens of thousands of nodes).

Over the fullness of time – perhaps intellectual property from one or the other will cross pollinate (we do that often).  Perhaps over the fullness of time, everyone will use vSphere and vSAN will win everwhere.  Conversely, perhaps, time will show that heterogeneous environments including Openstack on KVM/Xen and SCOM on Hyper-V and vCloud Suite + vSphere will continue to coexist.

One thing to point out – BOTH VMware and EMC have an open posture – working inside ecosystems beyond ourselves.  We both contribute to OpenStack (nova integration for ESX, neutron for Nicira, vCAC with the whole kit and kaboodle, Cinder for EMC storage, Swift in ViPR) – and this is sincere.  This openness is important.  My point about the “two perspectives” originates from the model of how VMware and EMC independently tackle solutions – with a perspective of what is “assumed”.

Regardless – VMware and EMC are out there trying to innovate and build solutions for the customer.

Hope that helps clarify!

Comments

[Forbesguthrie]

Hi Chad,
You say "(vSAN) It's deeply embedded in the VMkernel (so it can't be used with OpenStack ...". I guess that depends on which hypervisor you choose to run OpenStack on.

[Chad Sakac]

@Forbes - that's fair - and I've corrected the post to remove that. It's a little tricky in the sense that the Cinder plugin generally expects a device to handle, but it is possible to create something that COULD work with the vSAN model. Thanks for the feedback/correction!