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]

Hi Martin.
I'll handle my part first then turn to the opportunistic heckling from the peanut gallery.

What do Iomega, Atmos and VPLEX all run on? Linux. They're all components which run on top of our secure Linux Distribution.

You can see the pattern.

As for Enrico, he's pushing a platform with a tiny amount of ports, running on a rusting 32 BIT OS, with awful useable capacity (NetApp bad) and doesn't offer any modern connectivity options.

That in the fact you pay a license tax with every 8 drives added.

I wouldn't wait 15 years. Those design decisions are problematic today.

[Martin G]

Zilla, I indeed see the pattern and building on top of your secure Linux 'distribution' (you aint distributing it very far now are you?) is a good start but even you've got to admit having three and arguably four block storage products is fairly profligate.

Even if you turn DART/Flare/Engenuity into personalities to run on top of your secure Linux... it's still a long term problem.

Or is EMC secretly running a developer job creation scheme?

[John Dias]

This is why I adamantly avoid talking about OPP (other people's products). I sell mine, you sell yours and let the customer decide.

When you introduce FUD into the conversation you only open the discussion up for your competition and engage in a meaningless (to the customer) rant that does nothing to solve people's problems.

That said, I do find the "8 drive license tax" comment interesting. Compellent's licensing model based on the number of drives in a system instead of raw capacity is beneficial in several ways - chiefly that drives do tend to get denser and less expensive allowing the customer to add capacity without increasing license cost by swapping higher capacity drives with existing ones.

The licenses cap out at 96 drives, by the way, so the "tax" is limited at that point. This is about 15% or so of the maximum drive count by the way. Finally, the licensing is perpetual - upgrading to the next generation system or newer drives will not incur a "death tax" to borrow Mr. Zilla's analogy.

[Enrico Signoretti]

Zilla,
this is not the place where discuss the Compellent's capabilities but you are not well informed on the # of ports, type of connections, operating system and so on.

And about the licenses, they are perpetual.
With EMC you need to buy new software for each hardware generation

[Storagezilla]

Martin: I wouldn't say that since Iomega alone ships more storage than EMC and many of it's Enterprise competitors combined.

A block interface is just that a block interface. It's three components optimised for different workloads found in different parts of the market.

It's the layered software on top of those that's more interesting and the monolithic method of developing software went out with the ark. While in some cases there are clear lines of delineation in others it's the branding and the component mix which makes the difference.

We've seen from other vendors that the concept of somehow merging everything into one giant mess has proven to be just that.

A giant multi-year development mess which won't ever deliver what was initially promised.

You need to move beyond thoughts of running Enginuity on an ARM processor in an Iomega box.

John: I didn't start out throwing these rocks I was writing an educational post but as you bring the point up licensing is a commercial discussion. Not a technical one. A technical one wouldn't change the fact that trying to have such a commercial discussion with a customer when offering them less CPU and cache per processor as found in a budget laptop isn't a discussion you could realistically have.

Now, I'm more than willing to go back to what I was doing or this can escalate.

[Martin G]

I am not suggesting you run Enginuity on anything and I'm not even suggesting a code merge. Perhaps a clean-room re-implementation?

Perhaps a re-evaluation of the product set?

Perhaps an architectural re-evaluation of your enterprise products as to what features should be provided where? Otherwise the interoperability matrix for your products let alone the third party products is going to be huge.

Perhaps EMC like the complexity but you keep trying to encourage your customers to simplify and standardise...I'm suggesting that taking some of your own medicine might not be the stupidest thing.

[John Dias]

Zilla, my admonishment wasn't directed at YOU personally but I can see how you would've taken it that way. I'm bowing out of this - as I said, no good can come of FUD.

[Storagezilla]

Simplification is amoungst EMCs priority this year but pulling resources from successful platforms to start on a blank page isn't how you simplify well.

Look at all the startups out there and amoungst their "magic" features look at how much of the basics are missing. Those basics also have to be written again.

The way to do it is enhance what the customers want and move as they move.

If they all flipped to CX or Symm or whatever then the market will have moved and you adjust accordingly.

But they haven't. Sales of all those platforms are up. Up a lot. And putting a bullet in the head of what's selling is a sure way to annoy your customers.

[Storagezilla]

Understood John.

Regards,
Z.

[Martin G]

So Mark, what you need to is ensure that the transition between your platforms is as seamless and painless as possible.

For example, you need to make easy for a customer who wants to have their development environment on CX to refresh quickly and simply from Symm. Perhaps even you might get people who refreshing from CX to Iomega.

You need to work to a common interface, removing complexity and standardising. Commonality of language and definition across your platforms.

Things like FAST should where possible work and be configured commonly across all platforms.