When F5 Networks Inc. introduced its ScaleN architecture to version 11.0 of its BIG-IP software platform in 2011, the company took a new approach to resiliency and scalability. It did away with the traditional architectures that required pairs of active appliances and standby appliances to maintain high availability, instead enabling what it calls an "all-active" environment that makes use of all available resources. Two-and-a-half years later, the company focused its innovation efforts on platform intelligence, adding more granular programmability and policy engines that can automatically and dynamically respond to sudden changes in the application delivery environment.
To that end, F5 is this month's winner of SearchNetworking's Network Innovation Award for the 11.4 release of its BIG-IP software, which introduced a series of new features allowing for even greater policy control in increasingly complex IT environments.
Features and e-zine editor Jessica Scarpati spoke with Alan Murphy, F5's director of enterprise marketing architecture, about some of the key features in the 11.4 release, areas for future development in platform intelligence and how F5's approach fits into a software-defined networking (SDN) strategy.
One of the newer features introduced, iCall, introduces more programmability to the BIG-IP software platform. Can you talk more specifically about what it does?
Alan Murphy: Let's say you're delivering a Web application through the ScaleN-enabled fabric, and the capacity for that Web application grows above 80%. You can have a threshold policy that says, 'When the application demand reaches 80% capacity, we need to grow the infrastructure through ScaleN. We need to give new application resources to that Web infrastructure, and then we might need to even provision new instances of the Web server itself or the Web application platform.' The workload -- or the workhorse -- that does that for ScaleN is iCall. It sees that there's a change in traffic behavior, and it applies the policy to that behavior.
It also does the scaling; it issues the fabric-based commands that say, 'We need new application delivery services in the cloud for this application.' It's the working component of ScaleN that does the mechanics of scaling as well as the logic behind when to scale and where to scale.
Is iCall at the heart of the programmability and intelligence F5 introduced with the 11.4 release?
Murphy: ICall is one component of it, and for F5, programmability is paramount. From day one, we have always designed an infrastructure that is completely programmable and manageable by the administrator.
We have programmability components such as iCall that do the workload management, and we have another programmability component called iRules for inline traffic management. IRules offers the ability to change and manipulate the traffic as it's coming through the fabric. So, if we need to replace sensitive content as it's going through a Web exchange or Web interface, we can do that with iRules -- that's programmability at the traffic management level. We have additional management tools that allow the entire fabric to integrate with existing management platforms, and that's done through a series of programmable interfaces as well.
The intelligence component is where policy management comes into play, and we're very much a policy-based infrastructure. A company can assign a policy that says, 'If an application is in the cloud, the only people who can access it are internal employees that are already authenticated to the internal infrastructure.' That intelligence is implemented through our management tools, but often those management tools are through a programmable interface as well.
From a product development perspective, what was the most challenging feature or function to bring to life?
For us, programmability is all about being able to manage and adjust and deliver applications throughout the entire lifecycle.
Murphy: The largest challenge we had was more of a progressive challenge. To realize this vision of a complete application delivery infrastructure fabric enabled through ScaleN, the primary barrier was getting to a point where all of our technology could participate in that fabric. We didn't want to have any caveats that said, 'You can use the fabric, but only for X, Y and Z.' Or, 'The fabric is only supported by one hardware appliance.' We had to create a delivery plan, and it's spanned about two years, as we were gradually building up all of the infrastructure components necessary to realize this vision. From the 11.0 release -- where the very first components of ScaleN were brought to market -- through 11.4, we had iterations where we were bringing in individual components. For example, for iCall to work throughout the entire fabric, everything had to participate in the fabric.
To overcome that, we were very deliberate and we had a very specific two-year road map that we executed on to make sure that every part of our infrastructure could participate in that. And as of 11.4, all of our technologies that are part of the F5 BIG-IP infrastructure can participate in that fabric, can be part of a ScaleN environment and can deliver on those services everywhere -- because we started from a very strict definition of how to get to that point over a two-year period.
Is this the end of the road map? If not, what's the vision is going forward?
Murphy: No, this is absolutely not the end of that vision. What we were able to do with ScaleN in particular in 11.4 is achieve a milestone in that vision, and that milestone is the fully integrated fabric. Where we're moving forward over the next couple of years is to continue to execute on that vision, bringing in new application services to take advantage of that fabric.
What we've done with 11.4 and ScaleN is build a highly resilient highway infrastructure that can dynamically change based on traffic and customer need. Now that the infrastructure is in place, we have a huge opportunity to work with customers and deliver on what they need for the application services side. We're looking at being able to apply the same application services that customers have been able to apply in the data center and we're looking at applying those dynamically in the cloud.
These days, the word programmability is often used in relation to SDN. How does F5's work on application delivery fit into an SDN strategy?
Murphy: Programmability … is all about the ability to touch and manage everything. If something is programmable or if there's a programmable interface to that, that means I can get in there and tweak it. Now for SDN in particular, that programmability is about making the network itself more dynamic, and through that, moving the network to many software features instead of hardware.
At its core, it's mostly the same [for us]. I go in and change the network just as quickly as I can go in and change the application services that I already do. For us, programmability is all about being able to manage and adjust and deliver applications throughout the entire lifecycle. We are doing the same for our own fabric, so [it means] being able to manage and manipulate the fabric through ScaleN in a very programmable way.
We work in [an SDN] environment just as well as we do in a more traditional hardware environment. But at the same time, as we continue to grow the fabric and scale out these application services, integrating with SDN technologies and specific SDN providers is paramount. Because if somebody's using a robust SDN environment and through their programmability tools, they decide they want to move all networking resources from data center one to data center two -- or from rack one to rack two -- we need to make sure that the applications are still available in that new, highly dynamic network environment.
If they scale the network, change IP addresses or do anything on the network side, [our appliance is] notified through that programmable interface so that the application can follow the network. Vice-versa, if we need to make an application change because a Web server just went offline or we need to provision new infrastructure resources because demand has spiked for a particular application, we can notify the SDN environment. Through that same programmable interface, we'll notify the network environment and they can scale their highly dynamic network as well. But that always has to be in tandem, so we always have to be aware of each other and work with each other.