EMC, the enemy lies within


| min

As I was reading this William Blair analyst report on EMC, I wondered how the EMC Federation operates. It must be hard. They must have swimlanes for different products, SEs, and specialists, so that they don’t constantly fight.

Here is an excerpt from the Blair report:

It’s fascinating to read how the “Baskin-Robbins” of the storage industry manages more choices than a Las Vegas buffet! VMAX, VNX, XtremeIO, ECS, Isilon, ScaleIO, VSPEX-Blue, Vblock, ViPR, DSSD, VxRACK, and on and on. Just the converged products are a handful: Vblock (VMAX), Vblock (XtremeIO), VSPEX-Blue (VSAN), VxRACK (ScaleIO), and VxRACK (VSAN).

  • Finally, EMC management was clear to differentiate VxRack from the not-so-secret launch of yet another EMC hyperconverged platform coming later this year based on VMware’s EVO:Rack reference architecture. While details are still fuzzy, it appears that the EVO:Rack-based EMC product will have the same underlying commodity hardware platform as that of VxRack but will integrate both VSAN from VMware and EMC’s ScaleIO software (an odd combination that we suspect is due to VSAN’s inability to scale to the same levels as ScaleIO). EMC reps will need a cheat sheet just to keep up with all of these new products.

And with ScaleIO, EMC will argue that SDS runs great out-of-kernel. At the same time, when selling VSPEX-Blue, they will argue that in-kernel SDS (with VSAN) is superior. My head hurts now. #swimlanes

While I wondered how they manage such complexity within, I stumbled upon another recent analyst report from the 451 group. It talks about how EMC manages these conflicting product lines: via strategies, taxonomies, families, architectures, and personalities. Here are some excerpts from the 451 report:

  • With the new VxRack Systems, VCE now arranges it portfolio in a taxonomy of three different architectures. The first category is ‘blocks.’ Built on ‘best of breed’ hardware components with a variety of SAN storage options, these are mostly aimed at traditional transactional applications – Oracle, SAP, SQL, Exchange, etc.
  • The second category, based on the new systems, is ‘racks.’ These are more ‘software defined’ in nature, and are aimed more at next-generation databases (GemFire, NoSQL, etc.) that are generally better suited to scale-out architectures due to their composite/distributed nature, and often high and unpredictable growth rates…
  • The third leg of the taxonomy stool is ‘appliances.’ This is where EMC’s EVO:RAIL bundle, VSPEX Blue, a hardware appliance built on VMware’s VSAN hyperconvergence software, resides. It is targeted more at small-scale environments outside of the core datacenter, such as remote office/branch office and departmental use cases.
  • So what is the VxRack? It will actually become a family of ‘personalities’ over time. As well as the initial system, which will be orderable from July and available in Q3, VCE plans to offer VxRacks built on the forthcoming EVO:RACK specification, which is built on VSAN for VMware-centric environments. EMC says it will offer more details on this, plus a preview, at VMworld 2015. It says additional configurations are also planned.
  • The first offering will be built on EMC’s ScaleIO software. This offers scale-out hyperconvergence running on commodity VCE-branded ODM server hardware from undisclosed partners.

And in the midst of all this, the basic EVO:RAIL product (EMC’s VSPEX-Blue) continues to struggle in the marketplace, as the Blair report comments:

  • Given dubious prospects for VSPEX-Blue, both architecturally (it lacks basic enterprise-class features like deduplication) and from a go-to-market perspective (hard to see EMC reps getting behind a product that has no EMC IP in it), VxRack was a logical move for EMC.


And similar feedback from blogs where EVO:RAIL (VSPEX-Blue) users continue to grapple with basic competitiveness:

The Enemy Lies Within

Oracle database — a single binary that makes $20B+ — is a single version of software for every workload. There is a single version of MS SQL Server, a single version of VMware ESXi, and a single version of Linux and Windows Server operating system. Why does EMC need 50 different products for different workloads? The same workloads that Oracle, Microsoft, VMware, and Linux handle with a single binary are the workloads that EMC delivers storage using 20-30 products — families, personalities, architectures, taxonomies, strategies, blocks, appliances, … spaghetti. To say that each product is in its own “swimlane,” and has a different use case, is utterly lazy, and lacks product and business design.

Business design, much like software design, cannot be an afterthought — one can’t fix it by applying bandaids; those are what we call “hacks”. The strategy of the Federation, with its taxonomy gobbledygook, is a pure and simple hack. EMC needs to go back to the basics, clean up overlap (like Oracle did), and build simple and elegant products that stitch together cohesively.

EMC continues to ruthlessly carpet-bomb the marketplace with new products, while already launched (new) products continue to beg for an iterative customer development cycle — a deep understanding of what it would take to bring true customer delight. And while ScaleIO and VSAN become the heat-seeking missiles that collide (and Vblock becomes the collateral damage), the EMC Federation thinks that the enemy to beat is Nutanix.

The real enemy lies within. It almost always does.