In the nine years since f5 CEO John McAdam took the helm, networks have become increasingly centralized, users have become more distributed and application delivery
What was your main message to Interop attendees this year?
John McAdam: IT agility. You've got commoditization of the data center driving massive centralization. It's interesting, what's happening is that the actual capital expenditure is going down but operating expenditure is going up. And that's really one of the things driving centralization. It's all about innovation, scalability, availability, and the key focus is the application.
How important is it for a networking manager or engineer to become a systems or applications expert?
McAdam: There is a big overlap now. It used to be when you did sales calls, you talked to the networking folks and they made decisions related to the networks, and then there was the group that talked about the applications like Oracle and Microsoft, and then there was the security group. Now we quite often get multifunctional meetings. What's going on now is that developers have built applications not thinking about the network, but of course now the network is critical because of centralization.
The way we train our people is to try to get to the application architect but not to ignore the network people, because they're critical for us.
f5's consistent message is to turn a stagnant infrastructure flexible. What does that mean?
McAdam: We started off with iControl (monitoring architecture) with the ability for applications to link an API into our product. That was a start, but the big jump was when we introduced TMOS proxy architecture that allows you to look at any flow of data—not just deep packet inspection but flow of data bi-directionally. And we can look at it without the customer ever knowing it. With that, we've created this iRules (command language for managing sessions) capability. So one of our customers, Facebook, uses iRules so, as they are producing applications on a daily basis, they can change those applications and optimize them as they need on the fly.
I'm assuming that works in a virtual environment also.
McAdam: Completely. Everything we do with an actual server we can do with a virtual server. We've done quite a bit of work with VMware and Microsoft. With iControl we can send a message to VMware to say, "There are some problems here," or "This part of the network is overloaded, and you might need to provision more virtual servers." It's an opportunity because while virtualization decreases capital spend, it also increases the complexity of management. For that, we do policy monitoring and provisioning.
I keep hearing about virtual applications. What is a virtual application, and how does it differ from a virtual server?
McAdam: A virtual server is one server divided into three servers (or more). A virtual application can be basically running on any of these [servers].
When you talk about needing a virtualized network, what do you mean? Your definition of virtual network seems to be different from what some networking vendors refer to.
McAdam: There are 10 different meanings of virtualization. The way we look at virtualization is when you make many components look like one, which we do in a whole load of different ways. But if you are talking to some big networking expert, you'd be talking segmentation and overlapping IP addresses. We introduced that in Version 10 (of Big-IP, f5's application performance, access control and security device).
The other thing we do is you can have various blades in the system and actually virtualize the application running so we can have it (functioning across the blades as necessary and on demand).
What are the security needs when it comes to application delivery in a virtualized environment?
McAdam: It's the same, but more complex. You get less control. That's where most of the big security breaches come in, so we do things like check cookies with HTP headers. We're fundamentally looking at the flow of data, policy by policy, within each head and within each content, so you can stop an attack.
The interesting thing is the ASM (application security manager) module in Version 10 introduced clustered multiprocessing capability, which speeds up dramatically looking at these application firewalls. We've speeded up sixfold. We've found scenarios where the customer saw the attack as a slow application, but in reality it was a denial-of-service attack. With application firewalls, we can see things like that and think, "We're not sure if this application is being attacked, but it's pretty darn slow, so let's just limit it to two processors." Or you could do rate shaping and say that application gets less priority than this other application.
What are your thoughts on baking security into the WAN vs. client-based applications or LAN-based?
McAdam: In Version 10, one of the things we've introduced is the concept of iSessions—and you can actually build a tunnel between one Big-IP and the other, and it's encrypted. So I think by definition it's getting baked in. If you want to do de-dupe, we've now got a software module that sits on top of BigIP as well.
Considering the tough economy, is there a trend toward simple compression and bandwidth throttling rather than applying optimization solutions?
McAdam: No, I don't think so. What we have seen is that the volume of lower-end products has been increasing. A customer that might have bought a 6800 last year is saying a 3600 can do this and I can delay [paying more now]. In terms of cutting down in functionality, I don't see that.
Now that Microsoft will bake in DirectAccess to Windows 7 clients and Windows Server 2008 R2, does that lessen the need for f5's secure access products?
McAdam: No. We're bullish on that. We're very close to Microsoft. It's going to need the whole concept of SSL everywhere, which is what we feel that we're in a strategic position to offer.