Application Defined Networking: The Next Wave

"But the reality is that SDN is not designed for Layers 4-7 and its focus on Layer 2-3--and specifically its packet-processing focus--has long been shown to be inadequate for managing application traffic at Layer 4 and above."

IT tends to deploy applications from the bottom up, where the network determines what it can deliver--but that's changing to a model where applications tell the network what it needs. Two processes will drive the change. First, the business side must set priorities regarding which applications are business-critical and which are less critical, and then ask IT to prioritize not only projects but also application performance based on business criticality. The second driver is the capabilities in private clouds that allow applications to be dynamic and mobile, which means they can scale on demand and move from location to location, improving uptime and performance.

Networking vendors recognize this shift:

• Cisco and HP are building multitenancy into enterprise data center networking products. Each tenant sees just the networking resources it needs.

• VMware, Cisco, IBM, Open vSwitch and OpenStack Quantum have the building interfaces to interoperate with physical and virtual L4-L7 network devices that offer application services.

• Startups like Embrane and Context Stream are building L4-L7 services like load balancing and firewalls into their overlay products, which are provisioned alongside interconnections.

• All of the data center networking vendors have plans to make their products programmable either via SDK, API or both.

• Application delivery controller (ADC) products like Brocade's ADX, Citrix NetScaler, and F5's Big-IP have API interfaces that offer programmatic access to ADCs.

The common theme is that network programmability from L4 through L7 is critical, and vendors are preparing for it. The goal is to let applications state their requirements and let the network satisfy them. If an application is going to need multiple servers added or removed, then connections must be load balanced across those servers. In addition, if you want to limit access to a few network ports, which is a good idea, then you need a firewall. These are application demands that need to be satisfied.

Here's the wrinkle: You can't simply point traffic at an ADC or firewall and expect it to process the traffic without being configured for it. Application network service insertion is a critical gap that needs to be closed so you can automate the entire application deployment process. Today, you can configure application policies and deploy them ahead of time, but that's part of a bottom-up approach where you configure the network starting at Layer 2 and ending at L7. Bottom-up works--look at all of the successful network deployments today--but in the future, a top-down approach in which the application tells the network what it needs will be the norm.

Supporting application mobility and dynamic scaling means using an application model where the networking requirements are defined as part of the application profile and can be applied anywhere, with any underlying hardware. You should know when you deploy an application which network services are required, like QoS, firewalling and load balancing. You also should know what other services and systems it relies on, and you should know if the application is sensitive to latency, loss or bandwidth constraints. All of these requirements can be defined into an application deployment policy that will be enforced through an orchestration or cloud system.

The pre-configured, bottom-up approach can't meet the dynamic demands required by private cloud architectures and applications. Dynamic environments need automation to run properly. You already know how to build and maintain fast, robust networks. It's time to get out of the way and stop thinking of the network as a static resource. Use what you have built to carry out the application priorities your business partners demand.