F5 execs: We're blasting virtualization beyond Layer 3

F5's Synthesis Architecture aims to virtualize networking functions in Layers 4-7

Page 2 of 3

Rivelo: For example, whether you're using VMware's NSX environment or Microsoft's Hyper-V environment for network virtualization, or now Cisco's announcement that just came out, those are all different solutions in the market segment. You'll be able to orchestrate your environment. And what I mean by that is design your environment and instantly deploy all the application services tied to that application and the network. You're getting the environment up and running in minutes, whether it is running on your prem or in the cloud.

From a pure technology perspective, the other thing we do is consolidate the services. When you deploy our technology, we have multiple services inside that. We carry services around performance, availability, security, mobility, just to name a few. So depending on what service or services an application needs, we can automatically stitch them together in one instance, and that reduces device sprawl, if you will. You need fewer devices, instead you're managing services. And it reduces the cost of the infrastructure for the organization. We did some interesting TCO models that [show] depending on the solution you can get anywhere from 50 to 80 percent five-year total cost of ownership reductions. 

[TECH TALK: IDG Enterprise CEO Interview Series

It really comes down to four things. One is the business benefit of application velocity, helping customers deploy apps quickly. But obviously, that means that they have to be available, reliable, secure. They need to perform in all those characteristics. The second thing we do is really increasing IT capability. We give you a platform that is hardware, software, and cloud, so that allows you to deploy your applications wherever you want and you're not making a hardware or software decision. You have a common platform, and you can deploy or let your apps sit, if you will, where they work best. We talked a little bit about the third benefit, which is reduced total cost of ownership. The fourth major benefit is really the future-proof environment. What I mean by that is we not only work with open industry standards and open technologies, but we are highly extensible. We open up our control plane, our data plane, and our management plane. So if you need to do something, you need to build a service that doesn't exist, that a vendor hasn't delivered, we allow you to do that. One of the technologies we use is called iRules. Over a third of our customers tend to deploy iRules when we look at sample data. So that means you yourself can create business differentiation. Where the industry may not be doing it, you can do it for yourself.

John, does your direction with Synthesis speak to a hardware-less future for F5?

McAdam: The short answer to that is yes. I think it's going to be an evolution, not a revolution. Obviously we will continue to use hardware. We just announced a DDoS service capability, where we've actually proved some of the DDoS prevention in hardware is much faster, and DDoS is by definition a volume type scenario. Having said that, we've completely embraced the overall concept of software solutions on their own and as a hybrid. So if you look at the solutions we've got, we don't really care if the customer wants to just apply a software-only solution or use our appliances or does a hybrid. The key to that is the fact that we've got this technology called Scale-N that allows you to scale across software and hardware, so you can scale up and down, you can scale across. Even more important is the fact that our BIG-IQ orchestration engine will manage a software version of our product the same way as it manages a system version and basically allow you to work either in a cloud or on-premises. We're really pretty flexible with that. But in terms of the actual question, yeah, I do think there's going to be more of a move. We're seeing that. If you look at the software solutions as part of our revenue, it's been growing pretty aggressively, but it's still a small part.

Talk about these reference architectures, which Zeus referred to as recipes for how people would deploy this. Explain how that works.

Rivelo: Let's give you an example. Because we have all these services, this catalog of services that we talked about, they can manifest themselves in lots of different ways. And because, as John pointed out, we can interconnect the fabric in different ways -- cloud, physical, virtual, etc. -- we can solve lots of different problems in lots of different places inside a customer's network. So, for example, we can do DDoS mitigation or protection, and that's usually a perimeter service, somebody coming into the network. But we could also secure a Web application, as an example, or we can provide intelligent DNS or even, for service providers, things like LTE roaming solutions. We created this concept of reference architectures because they're actually the real problems that customers are trying to solve. And they can solve all these problems using the same component. It's just how you enable the component and what services you decide to enable at that place inside the network. We launched 11 reference architectures. They come with what we call a bill of material, or BOM, that has nine components inside that. That's technical documentation, solution diagrams, architecture diagrams, etc., helping our sales organization and our channel partners take that message to the customer. They are recipes. That's a way to look at it, ways of cooking up, if you will, the Synthesis portfolio, and we will continue to keep these reference architectures up to date as well as build new ones. It isn't as if 11 was a magical number, it was just what we could take to market based on the work required in the first stage.

Most customers, certainly in the enterprise space, are not yet at the point where they're actually deploying SDN; SDN is a fairly emerging trend, although it gets a lot of press. Is there value for them in this Synthesis architecture before they even get to SDN?

| 1 2 3 Page 2