Q&A: Duplessie dissects storage networking

In addition to being a columnist for Storage Networking World Online, Steve Duplessie is founder and senior analyst at the Enterprise Storage Group. Beyond that, he is a very opinionated and entertaining guy. As such, he seemed like the perfect person to query about what was hot in 2002 and what will be hot in 2003.

How would you characterize 2002 in terms of its overall impact on storage networking? What were the highlights and lowlights?

The highlights in 2002 were that we finally got society to a state where it now is completely motherhood and apple pie that networked storage is the way of the world. Things work now, they are less complicated, albeit certainly not easy, but when you understand what the right pieces are to put together, stuff actually comes together. We saw massive market adoption improvement in the big guys.

What was bad? I think the only negative was that it took six months too long to get iSCSI through the standards body, because that is really just the next manifestation of real goodness for networked storage.

What significant events or trends do you expect to see in 2003, and what impact will they have on users?

I think we will see an acceleration in incremental new network storage because of all the good work that was done in 2002. In 2002, all the primary data centers became networked. In 2003, you will see that continue to evolve, as well as move outside of just the big guys. It will start to be more commonplace among the tier two and tier three application environments.

On one hand, we have storage vendors swapping APIs; on the other, we have developing standards. How do users stand to benefit or suffer as a result of these two trends?

The good news is that we are actually moving toward more standardization. But it's important that we caution real people and users to say that that doesn't mean everything is going to work together, because Fibre Channel's always been a standard, so we don't want everyone to have false hopes.

So it's good that we all start doing things in a common way, but anytime there is room for interpretation, people will interpret things differently, and as such, things will not work together the way that they should.

Having said that, in the interim, we have no issue with people swapping APIs. There are a hundred different side deals that have gone on between all these vendors, and any way we can help end users manage heterogeneous, complex environments - whether that be APIs or, at the end of the day, Bluefin and CIM - is good.

However, for the next two years, we're still going to need API swaps, so I don't think users care. They say, "I have a problem, help me solve my problem. How you do it, I couldn't care less."

Is 2003 going to be a good year to construct multi-vendor SANs? Why or why not?

I think from a technology perspective, we are at a point in time where we can create solid, multi-vendor SANs. I think from a practicality perspective, 2003 is still not the year when that will happen. Technology will have caught up to enable it, but emotion and individual philosophical differences will not, and as such, most SANs will still remain homogeneous for 2003.

Expand on what you mean by "philosophical and emotional barriers."

It takes us longer as individuals to believe our own eyes. So we can prove it technologically, but there is still something in the back of that user's head that says, "Hmm, all those problems of a year or two or three or four ago. I know that I can get better economies of scale if I had a single SAN for all of my operating platforms, but I just still don't quite trust it."

How would you evaluate the industry role being played by the Storage Networking Industry Association (SNIA) in terms of the Storage Management Initiative?

I think they've done a good job by being able to corral the cats. All these vendors that run down absurdly different routes all the time are trying to solve the same problems. But they are a difficult bunch to get together and have them agree on lunch, let alone any of these other meaningful things. I love the SNIA for its efforts in getting all these guys to at least march down the same street, or in the same direction.

How do you feel about the Supported Solutions Forum?

I thought that was a wonderful concept that didn't turn out to have much teeth. The concept calls for putting all marketing and marketing dollars and external influences aside, and I thought it was great because it was imperative in theory that if a user was only going to deal with supported solutions, it was imperative to make sure that a vendor make sure its stuff worked, and worked seamlessly. Unfortunately, that became political, so I'm not sure users put a ton of credence into it.

What is your take on the newly created SNIA Customer Executive Council?

That's also good. If there was one knock on SNIA, it was that they were like a bunch of Hollywood actors telling each other how great an acting job they do. It was all vendor oriented, and there weren't any real people to help guide the process. I don't know how successful it has been in attracting real people, but it has to be an improvement.

What is the state of storage resource management?

SRM is a visualization tool that enables users to see what they have in their storage world from a physical perspective, as well as from a logical perspective, meaning, what is the type of data and who are the causes of those types of data in that environment.

So, the reality is that SRM is not a business - it's a feature to an overall management environment. That is the reason why most of these guys have gotten sold in the last year for $23 million and not $400 million.

Is SRM overblown as a concept?

No, I think it is absolutely dead nuts on. The reason that it wasn't a successful business is that traditional SRM told you you were ugly, but it didn't help you fix yourself. Nobody wants to hear that they're ugly.

But still, SRM was nice to have, but not an absolute necessity. We've migrated the concept of SRM to active SRM or ARM - automated resource management - where not only do I tell you you are ugly, but I give you a nose job if that is what your policy says. That's far more functional and useful.

This brings us into the realm of automation.

You could say that automation is not SRM, that provisioning is not SRM. But you could also make the argument that those are the actions taken based on information derived from fundamental SRM. So, we've sort of expanded our horizon to say, "What are you going to do about me being ugly?"

In the provisioning world, for example, me being ugly is analogous to it taking five different people and 1,000 steps to provision a storage array out to an application. So automating that makes me prettier in that task.

In terms of other elements of automation, an application should understand what its needs and requirements are and be able to eliminate a lot of the manual processes that get in the way of the application. So automation tools, which are kind of the next wave, should be application-dependent, but they should also be able to physically control the infrastructure in an automated fashion that benefits the application.

You're talking about automated storage provisioning, and we are starting to see some product announcements in that area. Is this technology stable and something that you recommend users implement, or would you suggest they wait?

I would not suggest that they wait. The problem with the industry is they try to boil the ocean. You know, we come in and we scared users by saying, "Automate everything," and nobody wants to automate everything because of the emotional issues, because we don't trust APIs.

We want to physically know where we have things and what we don't have, so provisioning is a universal pain in the butt for IT people. They do it all the time, and sometimes it's no more than a collection of Perl scripts executed the same way: How do I create my LUN on a Hitachi box, and get it out and send it to this worldwide name, on this Brocade port, up to this host bus adapter, and create the file system, and create the volume, and all these other things?

That kind of stuff is perfect to automate because it is manual labor of limited value but of maximum negative value. By that I mean it's not strategic to the organization, it's just something that has to be done, but if you screw it up, it has significant negative potential impact.

Policy-based service level SAN management is being talked about quite a bit. What is your opinion of that trend?

Storage management by and large has been an oxymoron. Policies and best practices and procedures are typically only terms actually implemented and used in the very highest end shops, typically around mainframes.

So when you move down to the SAN, which is non-mainframe - it's usually a distributed type of world - anything that has a centralized place to invoke corporate policies and best practices is a good idea.

Whether or not that ultimately means you're going to completely automate all those things, I don't think so. But to have at least a common way to do all these manual tasks is a great idea. If you add a server, then you do this. If you add storage, then you do this. You should end up with a book of best practices or automated policies. A lot of the times, the same management and policy-based stuff is not about what you can do - rather it enforces what you can't do.

For example, you will not touch this other volume. You will not put this under this set of backup criteria, or this set of disaster recovery criteria because it's easier for us to believe that people will screw up than it is to believe they won't. So a lot of these policies are set up to prevent you from doing bad things, as opposed to automating good things.

Let's do a little word association here. I say a word, and you say the first word or words that come to mind. The first word is virtualization.

Stupid.

Vendor lock-in.

Dumber.

Tape backup.

Changing.

Fibre Channel.

Finally.

Storage management.

Money.

If you were king of the storage networking universe, what would be your first decree?

I would decree that everything from an interface perspective will absolutely be standard. Not variably standard, not interpretively standard. There would be one way to connect everything.

Copyright © 2003 IDG Communications, Inc.

  
Shop Tech Products at Amazon