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.
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.
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?
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.
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
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.
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.
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.
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.
Understood John.
Regards,
Z.
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.
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.
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.
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!
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