This syndicated post originally appeared at Zeus Kerravala's blog.
Earlier this month, F5 announced its ScaleN architecture designed to make it easier for companies to deploy a software defined network and extend virtual networks to the cloud. ScaleN can be thought of as a unified set of virtual and physical infrastructure that has been configured to optimize SDN environments. ScaleN also provides a new feature called iCall, which is an extension of its popular iRules scripting language and gives F5 ADCs the capability of dynamically reconfiguring based on the real-time status of the ADC infrastructure. The iCall technology allows for applications or networks to interface with the ADCs to trigger the reconfiguration.
Looking at this functionality, it’s easy to see that there’s significant overlap with traditional SDN controllers. One of the value propositions of SDNs is that the controllers offer a set of northbound application programming interfaces (APIs) that give applications more control of the network. F5’s iRules has given customers the ability to create custom features to handle network and application events. But iCall brings automation to F5 infrastructure, removing the need for manual intervention. It would seem that much of the value of the SDN controller is being wrapped into the ADC, and why not? The application delivery infrastructure already sits between the network and application tiers, similarly to how many of the SDN controller vendors position their products.
The ScaleN architecture broadens the role of the ADC to now include virtual networks and support for SDNs by supporting both VXLAN and NVGRE, the protocols used by VMWare and Microsoft for virtual networking. So now the virtual tunnels no longer have to be initiated and terminated in the hypervisor or controller, but the ADC can dynamically create virtual networks based on automated triggers configured through the iCall programming interfaces.
As the name would indicate, ScaleN gives deploying customers the ability to scale the infrastructure in both breadth and depth through F5’s virtual clustering multiprocessing (vCMP) technology. The easy way to think of vCMP is to consider the F5 infrastructure as a “pool” of resources that can be allocated on an on-demand basis. So if a customer had five F5 boxes, they could be pooled together to create one, large virtual ADC. The ADC could then be carved up into a number of smaller, virtual ADCs that could be scaled up and down based on policy. This gives customers additional flexibility as it allows resources to be directed to applications, as required in an automated way, rather than having to provision things manually.
Software defined networks are supposed to make building and managing networks easier than what was in place prior to the deployment. This definitely works in F5’s favor, as the Big-IP platforms are currently widely deployed across companies of all sizes. If customers can use the ADC as the control point for software defined networks, doesn’t that make the environment simpler? Obviously, the ADC can’t fully replace an SDN controller today, but F5 did acquire LineRate systems a few months back, indicating that the company clearly has no intention of giving up any control of the data center.
As part of the July ScaleN announcements, F5 also announced the general availability of the new 5000 and 7000 series products. All of F5’s products have now been upgraded and are all at feature parity, so the iCall features as well as ScaleN architecture are available across the whole product line.
It’s my belief that the F5 announcements are a sign of things to come. ADCs from all vendors, not just F5’s, are on a collision course with SDN controllers. The industry certainly doesn’t need two control points, and ADCs have the incumbent position. This should be an interesting market to watch.
Latest posts by Zeus Kerravala (see all)
- Forget Heliocentrism-Embrace the cloud and Zeus-centrism - April 17, 2017
- Avaya’s post-bankruptcy plan should not impact customers, partners - April 14, 2017
- There’s never been a better time for Cisco Services - April 12, 2017