NetApp - Dave's Blog

Appliance Philosophy (The Network is the Backplane)

There are two ways to identify potential network appliances. I won't claim we used these techniques when we started NetApp; I understand appliances much better now than I did then.

1. Appliance-ize Hardware Components
   The first way is to look at all of the different hardware components on a fully configured general-purpose computer. Pull them off and attach them to the network instead. My computer has a direct attach printer? Pull it off and make a network printing appliance. My computer has a monitor and keyboard? Pull them off and make a thin-client.
   
   Of course, network storage is in this category. Pull the disks out of my computer and attach them to the network instead.
   
   When we started Network Appliance, we chose a very generic name because we believed that there would be many more appliance opportunities beyond storage. At that time, network storage was such a small niche that it didn't occur to us that there would be decades of growth for our company just within that one space. We were already looking for expansion opportunity. At this point, all of the appliances in this category have been taken. People have made appliances out of printers, tape libraries, monitor/keyboard—pretty much the whole 1980s-era general-purpose computer has been shredded into appliances. Cisco even pulled off the network ports and created the router.
2. Appliance-ize Common Applications
   The second way to identify appliances is to look in a large data center and identify applications so important that they have lots of general-purpose computers dedicated to them.
   
   Hey, we've got lots of e-mail servers, let's build an e-mail appliance! That led to Mirapoint and IronPort, for instance. People have also built appliances for database, web service, firewall, VPN and web caching.
   
   Interestingly, network storage is in this category as well. Before storage appliances, people used large numbers of general-purpose computers for network file service.

At this point, my instinct is that the appliance-revolution—the idea of turning everything that you can think of into an appliance—has become quite mature. Today, most startups at least ask whether they can offer their technology as an appliance. Sometimes I wonder whether this trend has gone too far. In a remote office, for instance, is it really easier to manage 20 appliances than to manage one general-purpose server with 20 applications?

I believe that this question leads to the most interesting appliance category to be invented in the last 10 years: the CPU appliance. Why not pull the CPU/memory subsystem out of the general-purpose computer and attach it directly to the network. No need for keyboards, displays, disks, tapes or anything! After all, when you have finished pulling all of the other hardware out of the general-purpose computer, CPU and memory is all that's left. Of course, I'm talking about Linux farms, blade servers, and the CPU virtualization tools that go along with them, like VMware, Microsoft Virtual Server and Xen.

I wonder whether the CPU-appliance will kill the whole second category of appliances. Why bother buying a custom appliance for my application if I've got an easy to manage, well virtualized CPU appliance that will run any application?

Right now these environments aren't as simple as they need to be, but I think CPU-appliance is the best way to describe the high-level trends that we are seeing in this area. Scott McNealy was so close. The network isn't the computer. The network is the backplane.

What do Marketing People Mean When They Say Brand?

Lately I've been hanging out with marketing folks, and I'm learning their language. That's scary for an ex-engineer, because to engineers, "marketing speak" means "meaningless double-talk". But having spent more time with these folks, I'm realizing that they are often onto some subtle and interesting issues.

An especially interesting word is brand. Of course, everyone knows that brand means the name you slap on a product, but marketing people also mean something much more subtle. One person explained it to me this way:

A brand is a promise that you make to the customer.

A brand is a promise? Meaningless double-talk! But as I thought about it more, it started to make sense. FedEx is a promise: "We will get it there tomorrow." Disney: "We will provide wholesome fun for the whole family." IBM: "We are the safe choice. You won't get fired for choosing us."

When marketing people talk about branding and brand management, they are—in part—talking about making and fulfilling promises. You will never see Disney-branded porn, because that would violate their promise. If FedEx wanted to offer "cheap shipping via slow freighter", I bet they'd invent a new brand name, because slow would confuse the FedEx brand.

Bad branding happens when a company makes promises it can't keep. For McDonalds, the promise of "fine dining to impress your date" wouldn't fool anyone. Worse, it would hurt the company's credibility. On the other hand, a well-managed brand helps customers know what to expect. It's always safe to take your kids to a Disney movie.

How does this relate to NetApp? Like most hi-tech companies, our brand as a small startup was "We promise you the coolest, most innovative stuff." You don't expect a startup to offer global support, enterprise quality, or advice on re-architecting your data center infrastructure. When we matured as a company, and developed those sorts of capabilities, we had to add new promises to our brand. It was a conscious effort to add promises and capabilities in parallel. We wanted to make sure customers knew what we could do, but we didn't want to over-promise, because that creates dissatisfaction.

Our new StoreVault division, focused on small and medium businesses (SMBs), created a new branding challenge, because the promises you make to an SMB are very different from the promises you make to a Fortune 1000 company. One key difference is that the NetApp brand promises "enterprise relationship", while the StoreVault brand says, "for a relationship, work with your VAR (Value Added Reseller)."

We are creating a new brand, StoreVault, to represent the SMB promises, because we don't want to confuse the existing promises of the NetApp brand.

Selling NetCache

I thought that our sale of the NetCache business last week might raise questions for people. How does an executive team go about selling part of their company? Why would they do this? What are the big issues?

We originally got into web caching during the Internet boom times of the late nineties. Back then, analysts projected that web caching would become a multi-billion dollar market. Also, we thought there were good technical synergies between web caching and storage. In both cases, you've got an appliance with lots of disks holding data that users access over the network. Finally, we believed that there would be a convergence between web caching and traditional storage. In the early dot-com days, people believed that everything would converge with the web.

Pretty much nothing turned out the way we expected. So much excess network capacity was installed at the end of the dot-com boom that caching to save bandwidth became less important. From a technology perspective, caching became more like network security than storage—preventing viruses from coming in, and preventing employees from looking at "inappropriate" sites. Web access protocols remained distinct from data access protocols. Instead of converging with storage, web caches were purchased and managed by the networking team, as part of the networking infrastructure. This made it hard for the sales force, which had to meet and sell to a whole new set of people who were not involved with storage at all. Finally, the caching market stayed relatively small—hundreds of millions rather than billions. None of these issues make web caching a bad business, but it never fit as well as we had hoped with NetApp's core business of storage and data management.

Exiting the business was tricky. Here are some of the key issues that we had to address:

1. How do we avoid hurting our customers?
   This was especially important because many of our NetCache customers were also big storage and data management customers. It's one thing to annoy customers in a market that you plan to abandon, but it's another thing to annoy customers that you hope to keep selling to.
2. How do we avoid damaging our Bangalore development site?
   NetCache was the first major project that we moved to India. We moved essentially all development and support for NetCache there. We were worried that selling or shutting down NetCache would tear the site apart, and force us to rebuild from scratch.
3. How do we avoid damaging our business model?
   How do we avoid hurting our revenue growth if we stop selling NetCache?

We are protecting our customers by arranging for Blue Coat to "acquire the assets of the NetCache business". As part of this deal, we "entered into a transition services agreement to continue product availability and support for NetCache customers."

Time solved the other two problems. Our Bangalore development site grew quickly, and added many new projects, but NetCache stayed about the same size, so at this point, NetCache is a relatively small portion of the overall site. Likewise, our overall revenue kept growing—now about triple what it was after the dot-com crash—but NetCache revenue did not. At this point, the NetCache revenue is a small enough portion of our overall revenue that the sale won't have a significant impact on our financials.

In summary, we've known for a while that NetCache wasn't as good of a fit with our core business as we had originally hoped, but there were lots of other issues we had to solve before we could get out of the business.