NetApp - Dave's Blog

Insanity Is What Divides CIOs And CTOs

I got this lesson from a customer:

The difference between a CIO and a CTO is a certain level of insanity. A CIO would never take a working infrastructure, turn it inside out, and redesign it. But a CTO will.

Another customer I talked with – a CTO – described his job this way:

There are five stages to technology adoption: monitor, evaluate, standardize, proliferate, and retire. I’m responsible for all but the fourth. It’s not my job to proliferate technology through our infrastructure, but it is my job to figure out when to proliferate, exactly what to proliferate, and – eventually – when to stop proliferating.

I asked for details about these different stages. He described monitor as a casual awareness of a technology, maybe from reading occasional articles or white papers, and keeping an eye on it to determine when to investigate more deeply. Evaluate is when you seriously consider whether a technology is valuable enough and mature enough for you to deploy. To make a technology manageable in a large enterprise environment, you standardize on a particular set of configurations and management processes. At that point, you can proliferate the technology broadly, until a replacement technology is ready, at which point you retire this one.

I’ve noticed that the CTO title is used very differently, depending on the company.

In tech startups, the CTO is a smart development engineer, often a founder, who has the technology vision for the company’s product. These technology-CTOs are deeply involved in technical details – the bits, bytes, atoms and electrons of the new technology.

In very large corporations, the CTO is often a person who reports to the CIO, and whose job is to define the technology vision for the company’s IT infrastructure. These IT-CTOs generally care more about the big picture – how all the different technologies fit together to solve a business problem – than they do about the bits and bytes.

Companies that sell enterprise IT products often have one or more CTOs who work closely with customers. These customer-facing-CTOs work especially closely with IT-CTOs, so they tend to think more about the big picture than about the bits and bytes.

Using the same title for different jobs can cause confusion. Sometimes when a customer asks to “talk with your CTO”, they want the nitty-gritty details about product technology, in which case the technology-CTO is the right person. But sometimes they want advice on enterprise data center issues – on large-scale deployments and optimal procedures and best practices – in which case a technology-CTO may be a bad fit, and a customer-facing-CTO would be better.

My opening quote was about CTOs who report to CIOs, but I recommend against asking for “the insane one” to distinguish between the different types.

NetApp’s VTL: Best for Tape Libraries You Can Park Your Car In

We’ve been shipping our NearStore Virtual Tape Library (VTL) for about 18 months, and it’s interesting to dig into what customers actually like about it. When we first shipped, we had a good sense of the important benefits. We believed that virtual tape would help customers:

•  reduce their backup window
• reduce their restore time
• reduce the failure rate of restores

We were pretty close.

For instance, one of our most popular features is fast hardware-based compression, which lets the VTL run just as fast with compression as without. Without special compression hardware, you would still save space, but performance would be much lower. Saving money (by using less disk space) is always important, but meeting the backup window is so critical that compression without performance doesn’t cut it. (Stay tuned for VTL de-duplication, next year, which will further reduce storage costs.)

On the other hand, I’m surprised how important creating real tapes from the VTL has remained. Despite all the hoopla about disk-to-disk backups, eighty percent of VTL customers still rely on tape for some part of their process. One lesson here is how reluctant people are to eliminate processes in their “data protection path”. I expect that customers will be creating tapes and offsiting them for the next decade, so “work really well with my existing tape infrastructure” is a critical VTL requirement. What has changed is that customers go to tape much less often. With VTL, most customers go to tape weekly or less, instead of nightly, which lets them get much more mileage from their existing tape infrastructure.

The interaction between virtual tape and real tape is a fertile ground for innovation. The ability to support many virtual tapes at once, and then write real tapes later, means that you don’t have to schedule multiple jobs to the same physical tape drive. A problem with one thread doesn’t affect everything downstream, which makes a chaotic system much more deterministic. Staging backup data on disks also allows you to run tape drives at full speed -- avoiding the stop-starts that kill performance. This helps stretch existing tape infrastructure still further.

A final thing we’ve learned is that our VTL is so powerful that we tend  to compete best in large data centers. At one point we explained to our sales force, “You’re odds of winning are best if the customer has a tape library that you can park your car in.” We have introduced smaller products since then, but we need to come down even further to cover the whole market. We’re working on it.