NetApp - Dave's Blog

Always Bet AGAINST Your Employees

Recently a group of NetApp managers tried to motivate their employees by betting that the team could meet a particular project milestone. If the team missed the date, the managers promised to dye their hair bright colors. (Silly hair bets have a long history at NetApp.)

Unfortunately, the team missed the date, and as a result, the managers not only had to deal with bad news, but they had brightly colored hair to advertise it. When people would ask, “What happened to your hair,” the managers had to say, “I bet my team that they would hit their schedule, but they missed.”

Even if there are perfectly good reasons for the miss, the listener might still conclude: You not only look like a clown, but you manage a whole team of clowns.

Much better to bet that your team will fail. When I first started running engineering (back in 1999), product reliability was an issue, so I bet my employees that they could not improve quality by a factor of 10. If they did, I would dye my hair any color that they wanted.

Imagine how this played out. The team succeeded (as measured by a man who cared so deeply about quality that I knew he would never cheat), and I ended up with hair that was bright magenta, blue, and red. To get hair these colors you can't put it on top of brown; you have to start by bleaching to white. So I looked like a freak, but at least, when people asked me about it, I had a good answer: “Let me tell you about my awesome team. I should never have bet against them.”

The conclusion: You look like a clown, but at least you manage a good team.

So I say, always bet against your employees. Of course, it helps if they understand it’s a bet you want to lose.

Why NetApp Is Winning

NetApp recently released financial results, and according to one analyst, “It was a supersonic quarter.” Never mind the financial details – I think the more interesting question is: What’s going on? Why is NetApp Winning? (Those who like details can check here. The quick summary is that our revenue was flat from a year ago, up 9% from the previous quarter. Profitability has also recovered.)

Two interesting trends are combining to boost our growth. (1) Many companies have an aging IT infrastructure and can no longer postpone capital purchases. (2) Server virtualization forces companies to consider new IT architectures, and that plays well to NetApp’s strengths.

When the dot-com crash hit, back in 2000/2001, many companies had recently updated their IT infrastructure as part of Y2K remediation projects. Internet companies and their suppliers had been growing so quickly that most of their equipment was new, and many of them went out of business so the market was flooded with “almost new” gear. It was a tough recovery for IT vendors. This time is different. This downturn began gradually, perhaps in 2007, so people have already been postponing capital purchases for quite some time. Partly this is intuition, based on talking with customers, but one metric we can track is one-year service renewals. In good times, people upgrade their equipment when their initial service contract expires. In bad times, they want to defer capital spending, so they simply extend the service contract by a year. In the past year, we have seen many one-year extensions, and we believe this reflects lots of pent up demand.

So the first key trend is that IT infrastructure is aging, and eventually companies will need to buy.

The second key trend is that server virtualization is forcing people to consider radically different architectures. I’ve had many customers tell me that their initial goal was to install VMware, but they discovered that in order to get the full benefit, they first needed to re-architect their storage infrastructure. NetApp was an early leader in storage for virtualized environments, so in many cases people have switched to our storage even when they were completely satisfied with their previous vendor. It’s not that the old vendor did anything wrong; it’s just that their products didn’t work so well with server virtualization. Virtual servers can be created quickly, so you need storage technologies like thin provisioning and cloning that let you provision storage equally fast. Virtual servers proliferate, so storage efficiency techniques like data deduplication become all the more important. The whole point is to save money, so good automation is critical. NetApp’s strengths perfectly match the requirements of server virtualization.

It’s hard to sure what’s happening. It could simply be that IT spend is picking up, and a rising tide floats all boats. If this is true, then you should expect similarly strong quarters from our competitors. On the other hand, it could be that NetApp’s strength in virtualized environments is allowing us to get much more than our fair share. It’ll take a few more quarters of results to be sure, but this is what we think is going on.

The Petabyte Era is Dead

Sometimes numbers have a symbolic value beyond any real meaning they contain. Like when your odometer rolls over to a hundred thousand miles. Of course, it’s all arbitrary, since a mile is just a certain number of Roman soldier footsteps, but even so, in a funny way, it feels like a major achievement.

At NetApp, we just had one of those magic moments: in the past 52 weeks we have shipped an exabyte of storage. That’s a thousand petabytes. Or 1,000,000,000,000,000,000 bytes. Look at all of those zeros! It has no real meaning, but I still love it.

The petabyte era is dead. Long live the exabyte era!

"I've Looked At Clouds From Both Sides Now" (A Non-Technical Definition of Cloud Computing)

I got a reader comment so perfect that it calls out to be shared:

I'm not the most technical tool in the shed, but I read a lot, and I have been reading a lot about cloud computing – and the lyrics of a song keep playing in my head:

"I've looked at clouds from both sides now
From up and down, and still somehow
It's cloud illusions I recall
I really don't know clouds at all"

Cloud Computing – how does it affect me, the person on the receiving end (security issues, reliability)? The definition of Cloud – Webster's dictionary:

·         Something that darkens or fills with gloom.

·         A dark region or blemish – something that obscures.

Again, average person with concerns.

Posted by: Evelyn Lindquist | October 27, 2009 at 10:41 AM

I’ve noticed that technical people sometimes love definitions that are so intricately detailed that non-technical people – including most business people – can’t understand them. I think Evelyn’s comment is a sign that cloud computing is suffering from this disease.

There are good reasons for people providing cloud services to dig into the technical details of what they are doing and how they are doing it, but I think that we need much simpler definitions for people using cloud services.

I just can't let Evelyn's definitions stand (gloom, dark region, blemish), so here is my attempt at a simple, non-technical definition of cloud computing:

If I am a business person and I have a business problem that can be solved with IT, there are two ways to go about it. The traditional way is to chose an application, find some hardware to run it on, find some storage for it, find space and power in my data center, find people to operate it, and so on. The cloud computing way is to find a service on the internet instead of an application I run myself, and to let someone else handle all of those other steps. I don’t own a data center, buy any equipment, or operate anything. All my capital expenses are converted to a service fee, or – more common in clouds for consumers – the service is free because I have to look at advertisements.

I’m not saying that technical people should ignore the important differences between various cloud approaches (Software-as-a-Service, Infrastructure-as-a-Service, Platform-as-a-Service, Storage-as-a-Service, Internal/External/Private/Public). But I do believe that we’ve got to figure out how to hide as many of these intricacies as possible from the non-technical people who just don’t care.

Cloud/Grid/Utility: Definitions Drift Because IT Is In Denial About Outsourcing

Why did the term cloud computing so quickly lose its original meaning? At first, cloud computing was about how to not build a data center, but it quickly morphed into an architectural description of how you should build a data center. The first definition is about accessing IT services over the Internet from computing resources that somebody else owns and operates. The second definition is about building your own hyper-efficient data center based on virtualization, shared resources, and dynamic provisioning. These definitions are so different – contradictory even – that it takes modifiers like external, public, internal, and private to tell them apart. To many, it seems that we have sunk into a morass of confusion.

My point here, though, is not to debate definitions or technology. (I believe that both internal and external clouds will be wildly successful for many years to come.)

My question today is why the definition got muddled so quickly, especially since this isn’t the first time it has happened. The original idea of utility computing was that computing should be like electricity. In the early days, companies had their own generators, but over time, centralized power companies replaced them. The theory was that IT should evolve in the same way. This same metaphor also inspired grid computing, but as with cloud computing, the definitions quickly shifted to data center architectures. I remember many data center tours where the proud owner of rack after rack of Linux nodes would say, “Check out my compute grid.”

What is going on here? I believe that IT is in denial. CEOs and CIOs are like ships passing in the night.

CEOs ask, “Why can’t we just convert to cloud computing?” What they mean is this: “I’m tired of expensive data centers, high capital costs, and hard to manage infrastructure. Why can’t someone else do all of that for us and we just buy it as a service over the Internet? You know, like Yahoo! email or Salesforce.com?” In other words, CEOs would like to outsource big chunks of IT, just like they have already outsourced big chunks of manufacturing.

And then the CIO comes back and says, “I figured it out. We can convert to cloud computing, but the good news is that we still get to build the data center and buy the IT equipment ourselves.” Ships in the night.

IT departments are so averse to the idea of having their jobs outsourced – who wouldn’t be! – that whenever someone tries to define a term to mean exactly that, they redefine it to mean a new thing that they get to build and run themselves. Perhaps soon there will be a creative new definition of external cloud that somehow means you build it yourself.

As I said above, I believe that both internal and external clouds will be wildly successful. For at least the next five years, more likely ten, most CIOs will run a hybrid model consisting of three main parts: (1) Traditional silos, where an application, a server, and storage are purchased and installed together; (2) Internal clouds, which will initially run less critical apps and grow over time; and (3) External clouds, which will also start low and move up.