* Silver Peak’s chief talks about the company’s origins and its preference for big-pipe environments
Founded in 2004, Silver Peak Systems is young compared to many of the players in the WAN optimization market. I caught up with CEO Rick Tinsley last week, who talked about the company’s origins and how its acceleration technology is geared for big-pipe settings — DS3 and OC3 data center replication and backup environments, for example.
Read on to hear some of what he had to say, plus stayed tuned for more. I’ll share additional excerpts from our conversation in the next newsletter, too.
NW: How did Silver Peak get its start?
David [Hughes, the company’s founder,] realized that the way enterprise IT organizations thought about their IT strategy was going to change. It was already evident three or four years ago that there was going to be a big trend toward centralizing storage and centralizing servers in the data centers and essentially consolidating a lot of the complex infrastructure in relatively few locations. That means that in order to maintain the same performance, you’re going to have to do something with the network to accelerate the access to that information for people who are in remote offices around the world. Also, unfortunately, with 9/11 and Katrina and events like that, it was clear that people were going to have to get a lot more serious about disaster recovery and business continuity strategies.
NW: Is that why Silver Peak chose to focus on big pipes?
Our vision is that all of the trends we’ve seen recently in bandwidth are going to continue. Customers are getting larger and larger links in their networks. Today’s T-1 line will be a DS3 tomorrow, and tomorrow’s DS3 will become an 0C3. People are going to continue getting higher and higher links in their networks, and that means they will need WAN acceleration products that really have high performance and can scale up as those bandwidth data points keep moving. So we’re very consciously trying to skate to where the puck is going in terms of the market.
NW: How do WAN optimization requirements change in a network that carries replication and backup traffic?
If you’re looking at a T1 line connecting an office in Wichita with five or 10 people, primarily those five or 10 people are accessing e-mail, and maybe they’re accessing centralized file servers. The number and variety of applications that are running over that link are relatively modest. Now let’s say you’re looking at an OC3 link running between Chicago and a disaster recovery site in Denver. That link has the same e-mail and file traffic, but it also has real-time replication, backup, and maybe SQL database accesses. It may have 40 or 50 different applications running on it. So in addition to a 100x capacity increase, you’ve got an order magnitude longer list of applications and types of traffic that are running on that link. So the qualities that a WAN acceleration product needs to have in this latter case are quite different. It’s very important not only that you can accelerate files and e-mail, but also that you can accelerate all of these applications and provide some traffic management and QoS capabilities.
NW: Some analysts have identified a trend for WAN acceleration vendors to create technologies geared for client machines. Is that something Silver Peak plans to tackle?
We can be considered the contrarian in some regard. It is true that almost every WAN acceleration vendor except Silver Peak is at least talking about a client. That seems to be an obvious feature or requirement. But we look at it a bit differently. Being a small company we think focus is very important, and we have a lot of very real customers who need WAN acceleration on larger and larger bandwidth links in their networks, and so that’s really our primary focus. We do have customers asking about client implementations of this technology as well… but all the client software vendors are already doing that, people like Microsoft and Citrix. The way we look at it, they’re probably better equipped than we, or any other WAN acceleration vendor, are to actually address those problems. We think we’ll let the other guys break their picks on that particular feature request.
