Application Delivery in the Age of SDN
Jim Frey is Vice President of Research, Network Management for Enterprise Management Associates (EMA) and is a featured guest blogger.
As the dust begins to settle from the hype storms around Software Defined Networking (SDN), one result is clear – we will never look at IT infrastructure, and networking in particular, in quite the same way again. And while much of the sniping and scrapping has been aimed at those seeking to commoditize the lowest layers of the network thus far, the long range objective of SDN is to bind network function more directly to the needs of the application layer in a secure, policy-oriented manner. While the essential enabling technologies have been proven out in a few high profile large-scale deployments, mainstream adoption will be gated by the maturity at the touch points between network consumers (a.k.a. applications and services) and the new network control architecture.
My EMA colleagues and I have been talking with a lot of network infrastructure and management tools vendors about their vision and role in future SDN-based environments, as we prepare to research the production readiness of SDN for the broader enterprise community. While the technologies are coalescing around virtual overlay networks and the separation of control from delivery, we still hear a lot of talk about APIs at the key touch points. OpenFlow is emerging as the de facto standard for southbound communications from SDN controllers to the network, but controller northbound APIs are still wide open and there are no emerging standards at that level. So what is at the other end of those APIs? The answer is "any number of things," with some of the most commonly cited examples ranging from traffic control to admission control, datacenter network virtualization, and even network and application performance monitoring, and maybe even application delivery controllers.
Let’s take a step back and look at where ADCs could fit into the SDN world. One viewpoint, voiced by Nicira founder Martin Casado, is that ADCs are an example of “network appliances” that need to be connected to virtual networks via OpenFlow, but are essentially just another network node out there to be “accommodated.” But ADCs are active, intelligent devices in their own right, and have information that could be relevant – even unique – for making network control decisions. Thus, this seems too simplistic of a view, or at least as one that ignores a better possible result.
Another option is to consider ADCs directly as SDN controllers. They influence path selection (at least between the ADC and its pool of servers) and they can be used to apply traffic and security policies. The challenge here is that under current SDN architectures, there is no concept of federating controllers, and thus if you want to be the controller, you have to be ready to control everything. Down the road this might make sense, if we are able to carve up and assign SDN control to network sub-domains, but otherwise this seems a bit far reaching.
The third and perhaps most immediately viable option is to look at ADCs as “SDN Applications” that would use the northbound API coming from SDN controllers to influence and direct network services deployment and behavior. This approach makes the most immediate sense, and is perhaps the most practical. ADCs play a very valuable role for optimizing application resilience, performance, and security, along with a rich viewpoint of operation health and status from which to draw command and control intelligence. This makes ADCs potentially smarter than your average SDN App, and thus likely more valuable as well.
Since SDN represents perhaps the best platform in history for consolidating and consistently applying network policy, it also represents a potential quantum leap in both performance and security control in the network. Since ADCs are inline devices, sitting in front of precious server resources and only a short step away from the most precious resource – the data – why should they not also play a key role in securing servers and data? ADCs already routinely provide SSL offload from servers – should they also take on admission control themselves? There is clearly an opportunity here for tighter alignment and, perhaps, consolidation across optimization and security objectives.
Should, then, an ADC be an SDN controller, an application using the northbound API from an SDN controller, or just another network node? Even though the SDN App appears the most logical direction, there may be use cases and environmental situations where the other models make sense. Regardless of which model ends up winning the day, the end benefit should be more holistic, effective, and secure optimization of application flows across the network and a positive step towards dynamic, software-defined IT infrastructure and services.
