Surgient gets vocal

Start-up Surgient Networks is planning to introduce a new switch at the upcoming NetWorld+Interop 2001 in Atlanta. President and CEO Nagi Rao and founder and CTO Scott Johnson spoke with Network World Senior Editor Deni Connor about the company's products and their use in the enterprise. They covered:

Surgient's competition
Dealing with bottlenecks
Approaching a down market in content delivery
The eQuilibrium architecture
Geek dreams

What problems are you trying to solve with your product?

Rao:We are trying to change the economics of the data center, its performance and cost of ownership, to the tune of 5x and higher vs. traditional systems. We can also significantly impact the revenue side of the equation because we have a predictable mechanism for delivering content.

Swiss Army knife of switches set to debut
More on the switch. Network World, 09/03/01.

How do you realize these benefits of 5x and higher?

Rao:The key to doing this is Scott [Johnson's] architecture, which collapses three pieces of gear into one. It collapses the networking, the computing and the storage gear in the data center into a single architecture. We call it eQuilibrium because we are convinced that in the end there has to be an equilibrium between the networking, computing and storage components in the data center.

You talk about the equilibrium between storage, networking and servers, and say that EMC, Cisco and Sun are on a collision course. Why is that?

Rao:Clearly they are encroaching on each other. Sun says EMC is its No. 1 competitor and has taken on relationships with Hitachi to compete in high-end storage. Clearly everyone is making moves on each other.

The reason you need all the network gear in front is because the server bottleneck has not been opened up. If the bottleneck were opened up between servers and storage, and servers could scale infinitely, then a lot of problems would be solved. eQuilibrium collapses the three spaces into an architecture that opens up the bottleneck.

Who are your competitors, and how do you differentiate yourself from them?

Rao:Content delivery has evolved from general-purpose servers of eight to 10 years ago to next-generation single-purpose appliances. There's a third generation that is beginning to evolve now where two of the functions - networking, storage and computing - are being collapsed, and one or more applications are being supported. We would argue that our product represents the fourth generation, where all three functions are collapsed and support multiple applications. Having said that we would end off competing against networking, server and storage vendors, but we see most of our competition with vendors who are putting these applications on servers or appliances.

Tell me about these bottlenecks.

Scott Johnson

Johnson: If you look at the data center, there's a network in front of the server and a network behind the server, just using different protocols. We've brought networking principles into the server in our architecture and broken apart the functions of the server into individual components. All the components - the storage, network and compute component - are connected by a network also. What we are dealing with are very high-speed engines to deal with all the protocols that are going back and forth between these networks.

We've removed the PCI bottleneck and the stack processing from the CPU both on the storage and networking sides. That's really how we have attacked the bottleneck.

Can you describe how your product fits into the network?

Johnson:[The eQ2500] can be placed directly in front of the router with storage coming out the back end, just as a server does today without all the intervening load-balancing and Web switches. What we are describing is one instance of the product. Where it fits is a function of which application is running. For example, if you were to run it as a network-attached storage head-end, the architecture would be a little different, and we would be sitting behind the server talking to it with disks coming out the back. If you were using our platform to run a Web-caching application, it would look somewhat different. When you think about these applications, they are largely protocol manipulation with some amplification pieces above the protocols, so it depends on what application you are running.

Analysts say your product is really going to tick off server, storage and network vendors. Why is that?

Rao:If you could somehow take a gigabit pipe coming out of the router and plug it into the server and pull unique content from a disk at gigabit throughputs and higher, then you wouldn't need a box such as ours. Today's infrastructure doesn't allow you to do that. In order to get to that solution, you have to collaborate with or replace multiple pieces of equipment in between, the physical media on which the data is stored and the network itself. It so happens that there are server, networking and storage guys in between. In a lot of installations, we will collaborate with many of the vendors the analysts say we will tick off.

Companies in the content delivery and caching area haven't been doing so well these days. How do you expect Surgient will be successful in these markets?

Rao:The problem we end up solving is for any I/O-constrained application. Rich media or content delivery is one of many applications that can be hosted on a platform such as this. For example, we have independent software vendors that are looking to port databases onto this platform for the simple reason that databases are I/O-constrained, just as caching and streaming media are.

Having said that, there is no doubt that the content delivery space is hurting. Our argument is twofold: We are not entirely dependent on the content delivery space, and two, in the content delivery space, we could affect the economics of the industry. Suddenly you are looking at a whole other ballgame.

You are focusing on I/O-bound applications such as caching and streaming, and then moving into databases and middleware applications. Can you give me some examples of middleware applications that could benefit from your device and tell me why?

Rao:One of the middleware applications vendors have been talking to us about is messaging applications. There are two reasons the platform is ideally suited for this. One is the throughput. The second one for the independent software vendors is that we do not have to make any changes to the core. That's a major source of comfort for our ISVs.

We can guarantee delivery of content. The engineering term we use for it is 'determinism.' What we mean by this is we can set policies and provide for service-level agreements (SLA) that enable prioritization schemes to be passed all the way from the network to the disk and back, so we can enforce QoS within the data center without any changes to the application.

We can manage this content and monitor against QoS. Partners will take the information from our box and spit out bills so you have transformed this into a mechanism by which content delivery can be monetized or internal SLAs between multiple departments can be enforced. For instance, an IT manager can give the finance division a lower priority than the operations division.

During the downturn of the past year, what has been Surgient's biggest challenge?

Rao:It was twofold: continuing to keep our focus on the problem at hand - i.e., we started off with the experience of 14 start-ups so we have what we call 'old-fashioned rules' of running the company, the first of which is frugality. One of the things we did not have to do was go from spending a heck of a lot of money to suddenly becoming very frugal. The second challenge was we had formed an advisory board, which had about 14 potential customers on it. Having that was extremely helpful during this downturn as the advisors worked to guide us through the issues on hand during the development process.

Where does Surgient expect to be in one year, in two years?

Rao:In the next three to six months, you will see two sets of announcements from us. One will be around the partners we will start working with, such as ISVs or billing vendors. Another set of announcements is reseller, partner and OEM relationships. The same thing that you identified for us - that there are three sets of vendors that we could potentially tick off - is also an opportunity in that they are looking at us solving a problem they have identified and want to leverage that.

How did you end up developing the eQuilibrium architecture?

Johnson: The key was to bring networking technology and functionality into the server itself. That implies not only high-speed connections between functional components with variable latency, it also implies QoS and SLAs between components and all the way out to SLAs to the level of content delivery to the client.

We've created an "intelligent services layer" that resides above the switched fabric and is OS-independent. It defines levels of QoS based on flows, groups of flows, content and user identification. That's handled below the operating system, which makes it easier to port software without changes.

Could you explain how your architecture relates to the individual blades in the box?

Johnson: We've created a platform that on the outside looks very much like a networking piece of gear. In fact, the design was created by people with a networking focus. The box has, like a typical server, a management blade, which is responsible for handling the policy-based QoS and SLAs that we present to the outside world and also is responsible for watching resource use and management of the other blades in the box. It's through this watching and its ability to control the communication links between the blades through the switched fabric, that we can be predictable. The rest of the box is broken up in a functional way. We have the storage processor that communicates through Fibre Channel to the disks; the networking and transport blades that completely offload the TCP/IP stack, including many variants of networking protocols such as UDP, RTSP, RTP; and the application processors themselves, which run Linux.

For example, one of our partners is interested in using the box to run storage virtualization software. You can take an application that was written for a general-purpose platform that is highly I/O bound to do a function that is very useful and hot in the marketplace, and see not only the performance enhancements but also effectively group the flows that have different priorities.

Take an ISP, for example. It is delivering content and has it on disks and starts noticing that response time is starting to slow down to customers because the service is overloaded. The ISP's response is today to throw another server in, which is fairly inefficient and inelegant in terms of the use of the hardware, space and power. You can argue that the economics of that is worthwhile. The problem is that in a rack of 30 1U boxes, it's irrelevant how much it costs to install that equipment - what costs money is managing it. It is totally inefficient to scale with the general-purpose architectures. With our solution, the bladed approach, our box like any other is going to run out of steam. Where the bottleneck is, whether it is in the network, in the processing or in the Fibre Channel - in these cases we can deploy blades to solve bottlenecks where they occur, without going out an buying a whole new server.

Is this balancing done by the customer on installation or is it done by Surgient?

Johnson: In the first instance, we have a fixed number of blades. We are shipping the product tuned for each application. In the eQ4500, the chassis, the management application will be able to vary the configuration and its performance. They will indicate to the customer where bottlenecks are, that something has reached a critical level, and will recommend that the customer will install X, Y, Z blades. When we 'geek out' and dream about the next-generation product, we have a vision of being able to pull from blades that have processors that are not being used at the time and automatically allocate them to the bottleneck situation.

Q&A: Surgient gets vocal

Related Links