NetApp - Dave's Blog

People Die

I have found that I can learn a lot about a customer's business issues by asking the CIO, "What bad thing happens if you can't access your data?" And of course, it opens the door for a discussion about the various ways that NetApp can help protect data.

I learned that if an airline can't access manifests and passenger lists, then their planes aren't allowed to take off. After 4 hours, if they still can't access their data, then every plane in their fleet is required to land at the nearest airport!

I learned that if a drug company can't produce the right drug testing data, even 10 or 20 years after the drug is approved, then the FDA can shut down production of that drug in every factory that the company has.

But my favorite answer came in Israel. In Israel it's easy to tell when you are meeting with folks in military or intelligence, because they all carry guns. The ones in blue uniforms carry small sidearms that they keep in their holsters during the meeting. The ones in green uniforms carry machine guns that they lay on the table in front of them during meetings.

So I asked a blue uniformed man, "What bad thing happens if you can't access your data?"
He looked back at me across the table, hand on his holstered gun, and replied, "People die."
It didn't occur to me until later to ask whether he meant his own people, or the vendor who sold him the equipment.

iSCSI Sucks, but that's missing the point. It's cheap and it's easy.

I’m frustrated about the way many people seem to be looking at iSCSI. 

People keep comparing it with Fibre Channel. They point out that iSCSI is slower, and less mature, and less reliable, and less quality of service, and more variability in packet latency. And then they argue that – as a result – iSCSI won’t be replacing Fibre Channel any time soon. 

That’s like arguing – in 1983 – that PCs won’t catch on because they suck compared to mainframes. iSCSI isn’t about replacing Fibre Channel any more than PCs are about replacing mainframes. Maybe someday, maybe not, but that’s not the point right now. 

iSCSI is about enabling networked storage in areas where Fibre Channel is completely impractical. If you think about it, Networked Storage has almost completely replaced DAS (Direct Attached Storage) at the high end. Pretty much all high-end storage these days (EMC, Hitachi, IBM, NetApp) is network attached, either SAN or NAS. Yet there are still billions of dollars of DAS sold per year. iSCSI is about converting the low-end half of DAS to networked storage. iSCSI is "networked storage for the rest of us." 

iSCSI’s biggest success so far has been for Windows servers running Exchange and SQL Server. I also see iSCSI getting traction for Linux. Over time perhaps mid-tier UNIX and eventually maybe even high-end UNIX, but now we’re getting into the "iSCSI versus Fibre Channel" question that gets me so annoyed. 

The two key drivers for iSCSI are cost and simplicity. Simplicity is much more important, so let me get cost out of the way first. 

Cost: It’s true that competition with iSCSI is driving down Fibre Channel costs, for both switches and for HBAs, but it is very hard to compete against free. Every computer these days is networked, so iSCSI adds zero cost. You can buy an iSCSI HBA if you want to, but iSCSI makes the most sense where performance isn’t an issue, so why bother. (On the other hand, the existence of iSCSI HBAs is a great safety net if you do have performance concerns.) 

Simplicity: The big win for iSCSI is simplicity. When I talk to people who have just finished an iSCSI installation, they say, "It just worked." No new hardware to add and not much to configure. 

I had a chance to visit the CIO of the Kuala Lumpur police department in Malaysia – hardly a hotbed of high-tech innovation – and he had just finished installing Exchange on iSCSI. His comment?: "It just worked." 

Why I'm Here

A big part of my job is listening to smart people who know about storage, digesting what they say and reflecting on it, and then turning that into my own opinion. Then when I share my thoughts, they get distributed randomly to whoever I happen to be talking to. Here are some examples of where my random thoughts ended up over the past year:   

Bright future in store for new storage protocol (ITWorld Canada) March 3, 2005

NetApp: 'We're not interested in going EMC's route' (SearchStorage.com) March 3, 2005    

NetApp Co-Founder Sees Expanded Enterprise Role (Computer Reseller News) March 22, 2005

Network Appliance Co-Founder Dave Hitz on Storage Cost Savings (E-Commerce Times), February 10, 2004    

Skimming the Cream (Network Computing Asia), February 2, 2005

   

So why am I doing a blog? I figured that if I'm going to be having ideas and sharing them, I might as well collect them in one place.

 

Information Lifecycle Management: Cost or Risk?

Customers often ask me about ILM, and what I think their strategy should be. This is a trick question, because Information Lifecycle Management seems to have two almost unrelated meanings, one about risk, and one about cost. See also EMC's ILM story.

The "risk version" of ILM has to do with regulated data. I call it "risk ILM" because the primary goal is risk management. How do I keep my CEO out of jail? When an SEC lawyer asks to see an old e-mail, how do I prove that the data I’m showing him is the same data that was stored five years ago? If I’m required to keep data for seven years, how do I ensure that it is deleted after seven years and a day?

The “cost version” of ILM is about saving money. How do I use less expensive storage for data that has lower performance or availability requirements? How do I minimize the amount of expensive high-end storage that I own and manage? The key building block for “cost ILM” is having tiers of differently priced storage, Ideally, you’d like tools to identify “cheap data” that’s living on expensive storage, and move it off, and you’d also like tools to identify when data on cheap storage becomes more important and move it to storage with better performance or availability.

What’s my point? The reason I think this distinction is important is that these two forms of ILM have such fundamentally different goals that it’s confusing to lump them together. These two types of ILM have such fundamentally different goals that to talk about an “ILM Strategy” as if it were just one thing makes no sense.

For “risk ILM”, the strategy is to identify risks and costs. In many industries, really bad things can happen if you don’t follow the data rules. For airlines, the FAA says that if certain data is not available, then the entire fleet must be grounded. For drug companies, the FDA says that if certain data about a drug is not available, then all plants producing the drug must be shut down. Let’s not even talk about what happens when the SEC gets pissed. The strategy isn’t about saving money on IT, it’s about avoiding giant risks, potentially about staying in business.

For “cost ILM”, the only point is to save money. Compare the savings of cheaper storage against whatever management techniques or tools you need to make things work, and run the math.

Either way there’s different solutions from different vendors, but just don’t get mixed up about which ILM you are talking about.