« January 2006 | Main | March 2006 »

February 2006

February 27, 2006

ILM is about Everything; Therefore ILM is about Nothing

ILM has been confusing people for years. I googled "ILM confusion" and got 107,000 results. "ILM hype" returned only 78,100 results, so apparently there is more confusion than hype.

This blog entry was inspired by Mary Brandel's article, "ILM: If it's not a product, what is it?" She observes that:
The concept of information lifecycle management has been around for a while, but the storage industry, it seems, is still trying to figure out exactly what ILM is. Consider, for instance, that in a recent survey of 252 users conducted by the SNIA End User Council, 42% said they "neither agreed nor disagreed" with the definition of ILM developed by the SNIA in November 2004.
She quoted one industry expert who said:
It's worse than virtualization as far as, 'What does it mean?'
Worse than virtualization?! (Note to self: write a blog entry on virtualization.)

How did ILM get so confused? The basic idea seems straightforward enough: As data ages, its value tends to change and therefore so do the requirements for quality of service. It is important to take this into account when designing data management strategies.

When ILM was first introduced, Steve Duplessie wrote an article (There's a new buzzword in town: Information Lifecycle Management) explaining that:
What's important to remember is that ILM is not a technology—it is a combination of processes and technologies that determines how data flows through an environment. By doing so, it helps end users manage data from the moment it is created to the time it is no longer needed.
Steve's comment helps explain the confusion behind ILM. Once a buzzword becomes hot, customers start saying things like "show me your buzzword roadmap" and "I want to buy some buzzword products". Given customer demand like this, you can count on the computer industry to start delivering buzzword products and buzzword roadmaps, no matter what buzzword originally meant.

But I believe that the biggest source of confusion is that EMC took the idea of ILM and decided to use it to explain everything that they do. At EMC, everything is about ILM. Go to www.emc.com, and you'll see ILM front and center. Now visit emc.com/ilm:
No matter where you are in the process of implementing your ILM strategy, EMC is in a unique position to help. We have the vision, experience, and solutions you need. Our best-of-breed platforms, software, services, and support help you succeed with ILM.
Dig into the links and you will discover that everything EMC does is categorized into this framework. When EMC upgraded the Symmetrix DMX, the press reported that "EMC beefed up its information life-cycle management (ILM) offerings with what it called the world's highest-capacity disk array." Now a disk array is ILM?

To me, this is kind of like EMC's own private Dewey Decimal System. The Dewey Decimal System is designed to organize and categorize all of the books in a library, and EMC is using ILM to organize and categorize all of its solutions, products and services.

It is the nature of categorization systems to expand over time. The "Transportation" category in Dewey Decimal expanded to include rocket ships, even though rocket ships weren't invented yet when Melvil Dewey created his system.

Once EMC starting using ILM to explain everything that they do, it was inevitable that the definition would expand. No wonder the storage industry can't figure out exactly what ILM is:
ILM is about everything; therefore ILM is about nothing.
(Having said all this, some people will say, "That's all fine, but I'm still interested in strategies for dealing with the lifecycle of information as it ages. Can you help?" The answer is yes—I have some thoughts on that subject, but they'll have to wait for a future blog entry.)

February 17, 2006

A Doctor Death Moment

I helped invent a new drink. I was on a business trip with a co-worker named Laura, and the flight attendant asked us what we'd like to drink. Here's how the conversation went:
Attendant: What would you like to drink?
Laura: Cranberry ...
Dave: Dr Pepper.
Laura: ... and vodka.
Laura wanted a Sea Breeze (cranberry and vodka), and I wanted Dr Pepper, but since we interrupted each other, the flight attendant got confused.
Attendant: You want cranberry, Dr Pepper and vodka?!
Dave: Huh?
Laura: Uh, sure, I'll have one. One third of each.
Dave: Make that two.
So the recipe for Doctor Death is one-third cranberry, one-third Dr Pepper and one-third vodka. It's better than you might expect. The sourness of the cranberry cuts the sweetness of the Dr Pepper, and together they hide the alcohol, giving the drink a dangerous kick, like a Long Island Iced Tea. Hence the "death" in the name. We named it after we'd each had two more. For what it's worth, I usually use Diet Dr Pepper, but I doubt that makes much difference—maybe cuts the sweetness a little.

The Doctor Death story is my favorite metaphor for innovation, because it neatly captures something that I've seen so often in engineering brainstorming meetings. Here's the key question:
Who invented the Doctor Death?
I guess you could say it was Laura and I, because we requested it, even though we didn't intend to. Or maybe it was the flight attendant when she repeated back what she thought she had heard, even though she got it wrong. Or perhaps the magic point of invention was when Laura decided to go with the flow and try this new drink, even though the whole thing was a mistake. Or maybe it was when I ratified her choice by ordering the second Doctor Death in the history of the world. In the end, I conclude that it was a group effort. None of the individuals involved would have come up with this on their own.

Back to the engineering brainstorming meeting: A group of people are working to solve a problem, and together they invent a new solution, but if you try to determine who actually "made the invention," it's impossible. One person suggests a solution that isn't quite right, but another person mishears it and repeats it back slightly modified, and the first person says, "That's not what I meant," but a third person says, "You know, that could work!"

In cases like this, there is no use fighting over credit. The result truly is a team effort that can only occur when people are comfortable enough to throw out half-baked ideas and open enough to hear a possible solution even in a mistake or a misinterpretation.

I've seen this many, many times and now I have a name for it: "Hey, a Doctor Death moment!"

February 15, 2006

The Story of VTL: Marketing Message, Cool Technology, Business Strategy

This is a public service posting. Last week we launched the NearStore VTL (Virtual Tape Library), and I'm going to summarize the marketing message, the cool technology, and the business strategy all in one short blog, along with my own spin. Think of the hours you'll save skipping the official launch, with all its video and white papers. :-)

The Marketing Message
To be honest, there are already quite a few VTL vendors (EMC, HP, IBM, FalconStor), and the message is similar for all of them. This is my version. Almost all of it applies equally to our competitors.

VTL simulates a tape library using disks. Virtual tape is better than real tape because disks are both faster and more reliable than tapes. Since a VTL behaves exactly like a Real-TL, you don't have to change your backup software or backup procedures.

Given that disk is faster and more reliable than tape, the primary benefits are no surprise:
  • Reduce your backup window
  • Reduce your restore time
  • Reduce failure rate of restores
These benefits matter because people's data keeps growing, but at the same time users want less downtime. Tape isn't keeping up.

VTL can't eliminate tape if your operating procedures require you to send tape offsite. Even so, by buffering backups on VTL and then writing to tape, you can get all of the benefits above plus two new ones:
  • Use fewer tapes by keeping incremental backups in VTL and only writing fulls to tape.
  • Use fewer tape drives because writing to tape from VTL speeds writes by eliminating tape stops-and-starts, thus writing more tapes per tape drive.
The Cool Technology
Although many of NetApp's VTL capabilities match the competition, it does have two interesting technical innovations: "Continuous Self-Tuning" and "Tape Smart Sizing". As a result, NetApp's VTL is extra fast and uses fewer tapes.

Continuous Self-Tuning ("Extra Fast")
NetApp's VTL automatically decides which backup streams go on which disks. If the load changes, it can change its mind. With other VTLs, the administrator has to manage the mapping between backup streams and disk drives. So ours is both faster and simpler.

A self-tuning storage system that automatically places data efficiently on disk! That sounds just like what WAFL does. You can see why Alacritus was a particularly attractive acquisition target for NetApp.
Tape Smart Sizing ("Uses Fewer Tapes")
Tape drives these days all have built-in compression. If the VTL doesn't understand that, then it won't write as much data as the tape could hold, thus using more tapes than necessary. NetApp's VTL does understand tape compression, so it uses fewer tapes—often a factor of two fewer. (Sounds obvious, but no other VTL vendor does this.)
Business Perspective
What is NetApp up to? I gave a framework for our top level strategy in my article on NetApp's Quantum Leaps. The key point was that our historic focus has been on enhancing our own storage subsystems, but now we are expanding beyond that into heterogeneous data management. Like the Decru encryption appliance, VTL is designed to operate with storage systems from any vendor. Decru and VTL are also similar in that we view both as stand-alone appliances and don't intend to integrate either into ONTAP.

Adding VTL to our product line gives us a larger target market and hence bigger potential revenue and higher growth rates. Equally important, it allows us to have much more interesting conversations with high-level customers.

Before VTL, most of our disk-to-disk backup technology worked only with NetApp storage systems. For CIOs who were not already NetApp customers, this limited our relevance. This was frustrating because NetApp was one of the first vendors to innovate in disk-to-disk backup, with technology like Snapshots (shipped in 1993) and cheap, ATA-based near-line storage (2001). But CIOs don't want to hear about cool technology, they want to hear about broad business relevance, no matter what equipment happens to be in their data center.

By adding VTL to our product portfolio, we can have business discussions about the advantage of disk-to-disk backup, and our long experience helping people implement it, whether or not the potential customer has any NetApp storage.

Summary
VTL (from any vendor) solves all sorts of important business problems. (Shorter backup window, faster restores, higher reliability.)

NetApp's Nearstore VTL has innovations that give it unique advantages. (Extra fast, uses fewer tapes.)

Most importantly, adding VTL to our product line lets us expand into the broader heterogeneous data management market, and it lets us have better business discussions with potential customers.

February 10, 2006

SAS Disks: The Next Generation of Something

After my blog entry on disk drives, a reader pointed out that I talked lots about Fibre Channel and ATA/SATA, but I didn't say anything at all about SAS (Serial Attached SCSI).

If you recall, I argued that disk drives come in two flavors: "commodity" and "value-add". The first is high-volume and inexpensive (e.g. ATA), and the second is higher performance and higher reliability, but also more expensive with higher profits for the disk vendors (e.g. Fibre Channel).

In this context, SAS confuses me. On the one hand, drive vendors are positioning it as a successor to Serial ATA (SATA), which ought to put it in the inexpensive commodity category. On the other hand, drive vendors are touting the advantages SAS has over SATA in duty cycle, MTBF (Mean Time Between Failure) and seek time. All of this sounds like the value-add zone, where one would expect higher margins and higher prices.

This confusion makes me suspicious. Is SAS a successor to SATA (cheap commodity) or a successor to Fibre Channel (expensive value-add)? Am I really going to get that FC-style reliability and performance at SATA prices? In short, I'm afraid disk vendors will charge high-margin "value-add" prices instead of low-margin "commodity prices", and I'll end up getting screwed if I rely on SAS as a true SATA successor.

Here's how I think about it:

    If SAS goes commodity cheap, competing with ATA, I won't trust the pricing stability until it is a high-volume commodity used in lots and lots of PCs or workstations. So I'm in no hurry.

    If SAS does go value-add, fast and reliable, competing with Fibre Channel, it's going to take time to build up the track record of quality that will allow enterprise customers to trust it with their valuable data. So again, I'm in no hurry.

But here's the good news: SAS connectors are compatible with SATA, so it's not hard to build shelves that take either type of disk. Most storage system vendors (NetApp included) seem to be designing their next generation SATA shelves so that they can also support SAS drives. (These products aren't all announced, but this is what I hear from friends of friends.)

This means that it's easy for storage system vendors to be well positioned no matter whether SAS is a commodity SATA replacement or a value-add Fibre Channel replacement. This gives me confidence that my wait-and-see attitude doesn't have a downside, even if SAS turns out to be wildly successful.

From a technical perspective, I like SAS. The connection to SAS looks a lot like SATA, and as a result you can build less expensive shelves. On the other hand, the guts of drives themselves are the same as high-end Fibre Channel drives, which means they've got good performance and reliability, and SAS has dual attach which also helps reliability. In some cases, only the firmware and connector is different between SAS and FC drives. Very cool.

So putting aside my paranoia and cynicism, I like SAS. I expect SAS to be the next generation of something. I'm just not sure what.

February 03, 2006

Cattle, Dostoevsky and Desert Isolation

Last week I went on a fund raising trip for Deep Springs College, a school I attended for two years starting at age 17. Now I'm on the board of directors.

Deep Springs is a college and a ranch. It has 27 students, 300 cows, and 120,000 acres of grazing land in the high desert east of the Sierras, on the boarder between Nevada and California. Deep Springs is a study in contrasts. The college is surrounded by lushly irrigated alfalfa fields in an otherwise empty desert valley of sage brush and sand. When you drive across Gilbert Pass into Deep Springs Valley, all you see of the college is a small smudge of green in the distance.

In the mornings students attend class, and in the afternoons students work the ranch. Another contrast: reading Dostoevsky then shoveling manure or pulling a breech birth calf from a heifer.

Deep Springs is also an experiment in student self government. Every year a committee of students selects the incoming students for the following year. Students also hire and fire the faculty. In both cases the college president has a veto, but that is very rarely used.

The stark isolation of the desert fosters a strong community. If you leave campus, you can walk for days without seeing another person. I once backpacked alone and saw no one for a week. (After four or five days of solitude, you begin to hear voices in the wind when it rustles the sage.) The isolation all around pushes in on the community to make it more intense. Fifty people – including students, faculty and ranch staff – share meals at the boarding house and rely on each other for everything. Interdependence. If I don't milk the cows, the rest of the community has no milk. If I leave the wrong gate open, a cow eats fresh alfalfa and dies of bloat. In a small group, no one can hide, everyone matters.

Deep Springs molded me more than any other experience growing up. Sometimes I wonder whether my aspirations for NetApp's culture are an attempt to recreate the feeling of community I loved at Deep Springs.

Recent Posts



Subscribe to Dave's Blog

RSS 2.0
Atom
© NetApp, Inc.  |  "Safe Harbor" Statement