Dealing with Legacy

Storagezilla's post on Clariion LUNs demonstrates aptly EMC's and many other vendor's problems with dealing the legacy; when I see gloating posts from the newer vendors, I feel very tempted to save the posts in order to bring them up in ten or fifteen years when they themselves are struggling to cope with an established customer base and legacy arrays.

Dealing with legacy is a big deal for all of the vendors; if you move away from the legacy, you potentially upset your customer base but if you continue to support the legacy, you find yourself building on more and more cruft. Customers with long established process, procedures and scripts are loath to change them. 

And indeed, even the vendor's own staff may well be treating the new features with suspicion. How many times have you sat in a meeting with a vendor's staff who tell you that they wouldn't touch that release of the code yet as it's too new and not 'Enterprise' ready. 

Yet vendors spend a huge amount of money QAing their code; 50% of product development time is often QA. However, we often get code which is still not bug-free and still often has some whopping bugs in it but in many ways, we as customers do add to the problem. We insist on using deprecated commands, not trusting the new features and generally insisting that the vendor supports features from 10-20 years ago. 

All of this adds complexity into the code-base; inefficiencies and mis-understandings creep in, bits of code become fossilised and no-one knows what they do anymore. 

However how does a vendor take its customers on a journey allowing them to transition to a newer, better way of doing things? I'm not sure but certainly their own field-staff need to show confidence in their own products; they need to redouble their efforts to ensure that nothing ships with service impacting bugs. Some serious thought needs to be applied to creating tools which migrate scripts and allow customers to move into new features. But there will always be customer resistance to change.

EMC's problems are fairly horrible for them to deal with; their plethora of product lines does make dealing with this legacy harder. And at present, we just see that product-base expand; even if they just turn all of their products into personality modes which run on a base platform, they will still have an ever expanding mountain of code to deal with.

To be honest, I think that at some point EMC will have to bite the bullet and consolidate their product-sets but which one? There are significant overlaps and the overlaps are getting worse not better; the low-end Clariion overlaps with the new rackmount Iomega and the high-end Clariion overlaps with the low-end Symm. And if we throw VPLEX into the mix? 

EMC are not the only company with this problem but they are the company with the largest problem due to the size of their install base, the maturity of the install base and also the fact that they make all of their own stuff. They have also been very good about ensuring a certain level of compatibility and retaining features for almost no good reason. 

Yes, they do deprecate hardware; I don't really blame them for this, the CX4 for example is significantly more powerful than the CX3. And with VMAX, it is a completely different processor architecture to the DMX.

Companies like IBM and HP, who at first look to have similar issues, do OEM at least some of their product base. And IBM were very ruthless when they moved from ESS to the DS8k range; changing CLIs for example. But they had less customers to piss off really!

But to poke at EMC, for at least trying to support their legacy and doing the right thing by the customer; is a little small. When you've had products in existence for as long as EMC and others and you find the magic bullet for dealing with legacy; then you can poke.

And yes, NetApp et all; your unified storage approach helps in that it reduces the number of code-bases that you have to support but don't pretend that there are not some wierd and wonderful legacy structures that you probably would rather not support. 

Comments

[Storagezilla]

You forgot the part about all that while continuing to add new features and pricing the products at $0.

I just want a clear list of asks Martin. ;-p

There are more than a few heterogeneous tools in the portfolio which will allow you to transition between Symmetrix and CX but were I to pick just one I'd choose RecoverPoint as it's something which people are using to do that test-dev to production aspect today and it will probably support VPLEX at some stage now that's off to the races.

Lanaguage and definition is already happening specific terminology has already started to be deprecated. As I stated in my post the Pool model is the model going forward and that doesn't deal with a lot of the previous concepts.

Unisphere is the midrange User Experience. I wouldn't foresee that encapsulating Symmetrix anytime soon as it's focused on the Unified Storage segment and doesn't have to deal with Mainframe concepts and the like.

SubLUN FAST will work in the same fashion across all supported platforms the way Virtual Provisioning does today, and recall that started out on Celerra in 2006, but the implementations will differ to account for specific requirements and system configurations for those market segments.

For systems with smaller caches you have to take into account metadata overhead Vs the extent sizes and the like.

I don't think anyone wants to develop a system which is mediocre at many things.

[the storage anarchist]

Martin - it's too bad you missed EMC World, as much of what you ask for was actually discussed. I did a session on array-based federation, for example, that outlined the path for seamless tech refresh migrations: first from DMX's, then CX's, and then (hopefully) via a new standard for LUN presentation.

And your point about cross-platform consistency is well said...and the development teams ARE making progress. Consistent SMI-S support across platforms and the new Virtual Storage Integrator are two examples where we present a single tool/interface that supports all of our products.

'Tis a journey, though, and not a destination. There will always be more that we need to do. And as 'Zilla said, it will be the customers who will untimately make the decision to merge or sunset product lines.

Until then, EMC spends more money and invests more people in EACH of our product lines than do ANY of our competitors in each market...you call for convergence, while we seek "integrated innovation" to drive each product to be #1 in its segment.

[Martin G]

Barry, sorry when I talk about refresh in that context; it's actually ongoing refresh; not a one-off event. Basically we are talking about replication between Symm and CX.

As Zilla says, you do have products such as Recoverpoint that do it...but it's yet another product.

I'm disappointed that the Unisphere product currently won't be expanded to Symm; I think that is a missed opportunity. I'm sure that the mainframe functionality could be built in. But then again, of course we have to be wary; don't want to produce another CC monster!

And as all vendors move towards a pool-based approached to storage provisioning and they will; I am hoping that at some point, we all will end up talking close to the same language. Life would be a lot easier for everyone at that point.

And Zilla, I really don't want the products for free!

[Chris M Evans]

Er

Isn't the whole point of VPLEX to do exactly what everyone is talking about, i.e. simplify data moves by inserting the virtualisation component. Forget the "private cloud" concept - Hitachi have been pushing the data mover aspect for years. I can't believe this isn't something that EMC wouldn't also like to achieve.

Chris