This is a very early warning of #storagebeers on May 13th but this is #storagebeers with a twist! I want the 'bods of the world to join in #!EMC-World!
So where-ever you are, gather your fellow bods be they of a storage, virtualisation or any persuasion and go to the local bar and partake of your favourite brew! The only place which is not permitted to hold a #storagebeers event is Boston!
I have a request and this comes down to fair representation and comment; I'm not going to shut down debate or even negative comments on my blog. I post things and you guys can throw rocks at them but...
I think it is only fair that I know who is throwing the rocks! So if you work for a vendor or a reseller of a particular product, I would like you to use your work-email address or link to your company's website. Or just declare it in your comment. If you don't want to reveal your work email, drop me an email to storagebod@spellen.org to declare and I'll be happy.
Put like this, bloggers have to declare their interests and pretty much all of them do; I think it's only fair and courteous for the commentators to do the same. It doesn't invalidate your views but it allows context. And I'm not going to out you as working for company 'A' or company 'B', most of the time it is fairly easy to tell from the tone of the comment who you work for.
Still, I would say that in general if you work for a company which sells a particular product, you should be proud of that product and should have nothing to hide. If you think the company you work for wouldn't like the comments you are making, I'd suggest you think twice before posting them.
Lots and lots of discussion in the blogosphere about storage efficiency; lots of guarantees, lots of rocks been thrown and general fun (or fud) for all. And then as the poor end-user, you scratch your head wondering what it all means and then of course, there is the thorny issue of infernal charge-back which causes storage managers eternal headaches unless you work with data which will not compress/dedupe :-)
It's time to change; it's time to stop guarantees which will promise me to be 50% more efficient than now; it's time to move to a model where I only pay for the data I store and the I/Os my servers consume. Of course, it now becomes a real incentive to store my data on as little physical storage as possible; the less tin you provision, the more you make.
Obviously, the first thing to do is produce a really good SRM tool which builds up a picture of my current data useage and how much I/O; this will be part of the RFP process and yet even more obviously will be carried out gratis. You can then bid for replacing the current estate, including migration costs and also a fixed price for increase in I/O and data stored.
As part of the bid, you will also include a cost for the environmentals; if your infrastructure costs more than that to run, you pay the delta and if it costs less than that to run, you keep the delta.
I'm sure some of my friends in user-land can add to the list.
No money-back guarantees, just guaranteed pricing...
There's a lot of talk about Dynamic Data Centres, Dynamic Infrastructures; mostly in a cloudy context and mostly as some over-arching architectural vendor-focused vision. At times, I wonder if when a vendor talks about a 'Dynamic Infrastructure'; if they actually mean, you can use as much of OUR infrastructure as you like? You can flex up and down on OUR infrastructure.
This is rather limiting from an end-user IT consumer's point of view because you still find yourselves locked into a vendor or a group of vendors. So it's only dynamic with constraints; actually, I think Amazon got it right in their naming, it's Elastic but not truly Dynamic.
So as a good architect/designer/bodge-it-and-scarper-type person, you should be asking this question every time; if I do this, can I get out? What is my exit plan? Can I change any key component of the stack without major process/capability impact? Is the lock-in which comes with any unique feature worth it?
And when I say any component, I mean all the way up to the application. So as part of the non-functional requirements of any application, there should be
1) Data Export/Import
2) Archival
standards defined and actually implemented. This goes for any off-the-shelf application as well.
For Cloud to truly change the way IT is done and delivered; this has to be done..otherwise the only way is vertically integrated stacks, which ultimately lead to long-term lock-in. There are still mainframes in existence, not only because they are the right platform for some workloads but also because people are struggling to unpick the complex interdependencies which exist.
I wonder if EMC regret their FAST announcements or certainly FAST v1, FAST v1 is pretty ho-hum and what most people are waiting for is FAST v2; sub-LUN, block-sized optimizations. But I wonder if Georgens is going to regret playing with semantics and trying to claim that tiering is dead when what he is really advocating is the same long-term vision as EMC, IBM and just about everyone else.
Most people at present believe that the for-seeable future of disk arrays, is two tiers, SSD/Flash and SATA and I see nothing in Georgen's statements which contradict; the only thing I see is an attempt to differentiate and pull the wool over the world's eyes. Tiering is here to stay and perhaps in ten years' time we will be talking about SSD being the bulk tier and some other technology being the fast cache tier but it will still be tiering.
So Tom, you can pretend that your eyes are only watering....but we know that they are tears!
So after dissing two of the major storage vendors and telling them how to run their businesses; I thought I'd post something less likely to upset.
I guess regular readers of this blog and followers of my never-ending tweetstream have picked up that I'm actually doing some hands-on at the moment; not just telling people what to do but actually doing. It's mostly been a bit of NetApp, IBM DS, TSM, GPFS, ESXi, Cisco and Brocade; all good fun. One thing I have noticed is that poor quality of the GUI management tools and the breadth of coverage in the GUI tools; I use the GUIs a lot because
a) I'm getting old and can't remember all the commands any more
b) I know the concepts but can't be bothered to learn the commands any more
c) If you only do things once in a blue moon, there's really no point in learning the commands any more
And it's c) which needs addressing; it's those things which you only do rarely that need to be present in the GUI tool but because they are rarely done, they don't tend to be in the GUI. For example, we're going to have to move some volumes around on one of our filers; it would be nice, if this could be done via the GUI; a simple drag and drop but it's not there, you have to do it from the command line.
On pretty much every storage device, there's a whole raft of operations which must be done from the command line; multi-step operations which would be nice if encapsulated at the GUI level. For example, migrating LUNs between arrays of the same type; a simple drag of the LUN from one array to another with the mappings etc carried out for you.
The GUIs have got a lot better but I think there is still plenty of room for improvement; so have a look at your command set and then compare it to what you can do from your GUI. If a command can't be carried out from the GUI, ask yourself whether there is a good reason? And then consider those multi-stage operations which could easily be carried out as a single interaction with the GUI.
Of course, as an old AIX admin; I'd like the equivalent of the SMIT option to show me what commands you are going to run, so I could then export them into a script and use that to automate in the future.
What a hornet's nest I stirred up with my blog; firstly it was good to see a lot of the NetApp guys coming out swinging in defence of their company, you should have passion for the company you work for but.....and there's always a but, it was not suprising to see that most missed the point! I was not attacking the Filer product, it is actually a great product for most people. However it is a single great product which you have built a business on but it is just a single product.
There comes a time I think that once a company gets to certain size and I think that NetApp are at that size; that a company needs to start to diversify. NetApp's performance on acquistion has quite frankly been terrible; perhaps Georgen's can turn this round and they can acquire and integrate well. NetApp for too long have traded on being 'not EMC'; I am not convinced that this is any longer a credible strategy which brings me on nicely to EMC..you didn't actually think I was going to let EMC off the hook?
EMC have exactly the opposite problem to NetApp; they actually have too many products and the 'Cloud' strategy actually sums them up! Their strategy is made of cloud, it's large, all encompassing and when you try to get hold of it; well....Put it like this, the average sales-man cannot articulate it, they don't even get to arm-waving bit, there's a blank look and then they try to sell you some storage. But at least you have Chuck's Blog!
So it's about time EMC started to make their sale-guy's lives a bit easier and shrunk their product catalogue. Clariion and Celerra need to become the same product line; yep, you need to copy NetApp and have a truly unified storage platform. You've got some bright guys who understand file-systems, containers etc; just admit the NetApp were right in the mid-range space and launch the Celariion. If you were feeling really brave, you could keep the gateway product and virtualise other vendor's disk.
Next have a look at the CMA area; what exactly does Documentum do for you? And when you start to drill down into the Documentum product set, there's some real cruft in there. Does anyone actually use your Digital Asset Management tools for example? The whole CMA area needs looking at and streamlining.
Ionix? A rebranding exercise at the moment. The whole product set needs integrating and you need to sit down with the people who use this stuff on a day-to-day basis, you could streamline and much improve this product set. And as your friends at NetApp seem to be asleep at the wheel with SanScreen; you could actually catch up and go past them.
Like Ionix, your BURA product set needs integrating and streamlining; the Avamar/Data Domain story is confusing customers everywhere, it makes us go cross-eyed at times. For example, we were looking deduplication last year prior to your Data Domain acquisition and you were trying to sell us Avamar against Data Domain; now you want to sell us Data Domain. Confused and we aren't the only ones!
EMC Consulting would be a good idea, not EMC paid-for PreSales which unfortunately it currently often turns into. You do have some good guys but stop brainwashing them and allow them independance of thought. I won't rant about EMC-UK but it's broken; if you want more information, contact me directly.
I think that like NetApp, you are in no-man's land as an organisation and there's a wonderful British expression 'eyes too big for your belly' which sums you up nicely at the moment! And like NetApp, you have some interesting challenges ahead and some interesting challengers but quietly and privately, you appear to acknowledge that.
I do want EMC, NetApp and all the other storage companies to succeed and grow; in IT infrastructure, it's the only place where there's any kind of product differentiation. The server market is quite frankly, boring and the network market suffers from the big kid in the playground syndrome.
p.s I've labelled my own post as FUD...because if a vendor had written this...I might have accused them of writing FUD!
After cursing OnTap for the millionth time this week, I am wondering where the heck the GA version of OnTap 8 is. OnTap 8 was announced end of August last year with a fairly large fanfare; indeed if you look at the NetApp pages, you'd be under the impression that it is shipping.
Unfortunately, I'm here to say that it isn't. Well, I guess that depends on what you call shipping; yes, I can go onto the NetApp support site and download a RC. But note that is still only a RC, it's not a GA product and I have a policy that involves not running production systems on beta-code.
And so I sit here cursing OnTap 7; actually I'm amazed that NetApp have had such an easy ride recently. Yes I love the ease of use and configuration of OnTap; yes, the snap functionality is probably best in class and A-SIS dedupe is very cool and surprisingly effective but there's an elephant in the room! The aggregate! It's so limited in scalability and it's becoming a real issue for effective and flexible management of storage.
The size of the aggregate really conspires against effective use of today's larger disks. I am a little surprised that NetApp for so long have managed to get away with claiming that they have wide striping; it's not especially wide IMO especially when you are talking about terabyte spindles. Even with the 300 GB disks, it's not that wide...
And then there's the file-system limit, 16 TB is pretty small.....
Face it, the aggregate is a right PITA! Hurry and ship a GA OnTap 8 please! People are fairly quick to throw rocks at EMC about the pre-announcement of FAST but with OnTap 8; NetApp can pretty much join them in the corner of shame. And at least EMC are shipping FAST v1 as a GA product and I would bet that FAST v2 is in a number of sites running as beta-code.
I wonder if FAST v2 will actually beat OnTap 8 to GA? So take up the gauntlet and get OnTap 8 out the door as a shipping product.
Sometimes I wonder if vendors become obsessed by maintaining compatibility with their old products that they are really hamstringing themselves. What is called pedigree could also be termed legacy and in IT, legacy doesn't really carry a positive image.
I wonder if for example 'OnTap 8' would be an established product by now if NetApp had not spent years trying to integrate Spinnaker and OnTap? And simply started afresh?
How much more mature would wide-striping and thin-provisioning be if EMC could have started again and not have to graft it onto existing systems?
And as customers, how much of the blame do we carry? We'll change vendors and hence infrastructure but suggest that we stay with a vendor but change the infrastructure; that'll cause major eruptions. The thought of having to migrate scripts, procedures etc, so we continue to hamstring our incumbent vendors.
Then 'new' concepts such as Cloud come along and still we insist that our incumbents maintain the legacy stuff ad-infinitum. I really think that some of the big vendors should be a bit braver about this but I doubt they will; in some ways this is good because it allows smaller vendors without a legacy to come through and challenge.
Also I suspect that there is a lack of confidence with some vendors; if you are going to force a customer to change infrastructure, processes, procedures and hence incur a cost of change; well they'll look elsewhere won't they? However if you really had confidence in your products, you wouldn't worry about customers looking else because yours is the best, isn't it?
Infrastructure Technical Architect, Support Manager and Geek Herder
Recent Comments