F5 has seen its share of market churn over the last half-decade - the telecom/dotcom boom and bust, the doldrums of 2002-2003 and the recent resurgence of the application acceleration market. Now the vendor is feeling the squeeze from new competitor Juniper and a resurgence in application switching focus from old competitor Cisco. F5 CEO John McAdam recently spoke with Phil Hochmuth about where the vendor stands in the ever-shifting Layer 4-7/application acceleration market.
How do you foresee the shake-ups in the acceleration market affecting F5 down the road?
If you look at fiscal 2004, we grew sales by 48 percent. That performance has attracted some larger competitors. We've seen Juniper make some moves with its Redline and Peribit acquisitions, and Cisco has been making some noise with its Application Oriented Networking launch. Overall, it makes our market more competitive. But it gives us opportunity because it makes the market as a whole more visible and creates opportunities that weren't there before. From that perspective it helps us.
Where is the growth in the Layer 4-7 market?
It's very much in enterprises and growing service providers. Finance and healthcare are big vertical markets for us. But any big company that has applications going out on the Internet, which is most Fortune 500s, whether they're running SAP or Siebel. Mobile is also a big part for us. Telco has gone from 10 percent to [18 percent to 20 percent] range for us. That's mainly from mobile. Anything service that has content being passed across the Internet, we play into that. We link the Internet world to the mobile world. Some of our partners are Huawei in China, Ericsson and Siemens mobile. They embed our products in their solutions.
With traditional network vendors - Cisco and Juniper - getting more serious about application acceleration, are you worried that acceleration features - Layer 4-7, as well as compression and offload - will just become functions of routers and switches?
We believe that you can do acceleration work in switches and routers, but it tends to be very limited in its features set. The more sophisticated you get, with encryption of data, and application firewall types - that can slow a switch down. The switch's main job is to get packets through. We're convinced you need to do Layer 4-7 tasks right beside the server, right in the data centre.
The XML acceleration market has received a lot of notice lately. How do you compare that technology to what F5 does? Or is this a subset of what F5 does?
We view XML acceleration as a subset of what we do. We've started introducing some XML parsing features. Frankly, XML data is still a small portion of the traffic that goes over the Internet. I think that needs to be held in context. But it's going to be a growing portion, as more apps talk to each other in XML. I see XML acceleration absolutely sitting in the traffic management area. Whether its XML or HTTP, we can secure it and optimise it. In our road map, we have more and more XML-focused capabilities coming. But just to look at XML is a mistake. You need to look at it as a subset of the overall traffic management solution you're installing.
What could F5 boxes be doing more of in the XML area?
It's all about how intelligently you can do XML parsing and security. You'll see us build in more intelligence so you can check XML data in a more granular fashion. It's all about granularity and intelligence in reading data, followed by building rules to control what happens with the XML data. For example, with SSL, we have SSL ASICs in our box. Our value add is the software that integrates with the SSL ASIC and manipulates the data, then re-encrypts the traffic. Over time we'll do that same kind of function on an integrated basis with XML traffic. Whether this will be done through partnering or through our [own R&D] remains to be seen. It will probably be a bit of both.
What is behind the push of moving tasks off of servers and into network hardware - such as security or protocol stacks or compression? How far will this go?
Three years ago, SSL was all being done in servers. Now it's typically done in our area. Compression is moving toward that. Now even authentication is moving down to our area. Not only are we doing SSL encryption and compression, but we're also taking application work off the servers.
The math is simple. We sit in front of 50 or 100 servers. Instead of doing a task 50 or 100 times, do it once on our box. That way you save yourself money and it's easier to manage and it tends to be faster. The trend will move a layer back toward the database, as well. You'll see devices like ours doing more, true application work.
Blade servers are being talked about a lot as the way new data centres will be built. Where does network intelligence reside if this is the way this plays out?
We saw this trend over a couple of years ago. It was obvious to us that blade servers over time will be significant in the overall data centre spend. So we invested in putting our software on blades: It runs on Intel, so it can run in Dell and IBM blades, and so forth. But what we've seen in terms of customer demand is that when they go to a large blade server implementation, they still prefer to have our box outside the blade chassis itself. They want a product that not only does traffic management for that one chassis, but for a number of chassis. Our customers spent much more money on us with products that sit outside the blade chassis than inside. Adoption of products that work inside the blade chassis has been slow. There's so much added value in having a product outside the chassis. I think that trend will continue.
Find your next job with techworld jobs