Where SDN falls down
Software Defined Networking (SDN) promises faster network deployment times and increased agility. Unfortunately, early SDN architectures focused only on solving connectivity challenges at layers 2 through 4 of the OSI model and largely ignored application-centric challenges at layer 4 to layer 7. Yet, layers 4 -- 7 are where many of the services reside that ensure applications are fast, highly available and secure.
Since the network exists to support applications, it follows that any new network architecture must address both the network challenges and the application layer deployment and management challenges. Enterprise-grade solutions, after all, demand more of the network than just switching, routing, and VLANs, so a more "inclusive" (or comprehensive) approach is needed.
Where current SDN architectures fall short is with applications that require any of the following characteristics:
Stateful networking.
Packet forwarding decisions at the network layer do not typically maintain state awareness. In contrast, application layer-aware technologies maintain state information about application layer transactions so the exchange of data and application behavior between those end points can be managed.
Message-based rather than packet-based decisions.
SDN operates on "flows" (for example, a TCP connection). However, application layer decisions are often based on HTTP messages, and a single flow might contain many such messages. Therefore, SDN is not well suited to applications that require message-based decision making.
Layer 4-7 context.
Simply put, many challenges cannot be met by simply focusing on Layer 2 and 3 data without any other context. Functions such as authentication, authorization, metering, message steering, cross-origin resource sharing, application attacks, performance, elasticity, fault isolation, SSL offload, and others require application logic, state, and message-based decision making, which occur at layers 4 through 7.
Adequate product implementations.
Due to design constraints, current SDN products are not being developed to handle application-centric (layers 4 -- 7) requirements. This shortsightedness limits many capabilities, such as computing power, addressing (flow) tables, and update frequencies, to name a few. When evaluating a new architectural paradigm such as agile data center networking, it's important to consider how that networking can be influenced by the applications and services for which it exists.
SDN's focus on connectivity alone did provide a far simpler starting point for the conception of "software-defined architecture." For example, connectivity-centric technologies have far fewer variables than what's required to manage application state and service-oriented policy. However, as many an early SDN adopter has discovered, a "simple" approach of minimal deployment services fails to address the human latency issues associated with SDN.
There are three areas of focus to ensure an organization's evolved SDN implementation is successful. The key driver behind SDN is the desire for a faster time to value for new applications and services. Organizations are frustrated with the excessive lead times required to deploy new applications and services that are designed to increased productivity and revenue. However, an SDN architecture designed only to deploy a small part of the network infrastructure will alleviate only a small part of the human latency that is inhibiting the desired realization. Therefore, organizations should consider an all or nothing approach to SDN planning.
Closely following the need for speedy deployments is the requirement for a faster time to react to both planned and unplanned circumstances. Much of the focus of SDN has been on rolling out new systems. However, managing existing systems is equally important. The reality is that requirements change over time. This could be due to organic growth in service demand (for example, for new features and functions), or unplanned circumstance like a cyber attack. Whatever the driver, the ability to react quickly ensures service uptime and helps protect an organization's brand.
Lastly, an inherent property of an evolved, more inclusive SDN implementation is the reduction of risk associated with managing many point solutions individually. This final point is a little more obvious. I see it in my every day work. I see it as I'm writing this paragraph. The more words I write, the more times I am required to hit backspace and make corrections. Fallor, ergo sum--I err, therefore I am! By reducing the amount of administrative touch points in any system, the opportunity for failure is reduced.
The issues that are driving delays in time to value for new applications and services and inhibiting change to existing applications and services can be solved by embracing an application-centric architecture. Let's not forget, the network exists for the application, not the other way around.
A hardware-free data center isn't a real possibility, but organizations should avoid building architectures in which the capabilities are defined by (and hinge upon) the physical devices themselves. Instead, they should strive to deliver an architecture that's inclusive of all network services--one that positions the physical elements of the data center as a reusable pool of resources that can meet computing, access, performance, availability, and security requirements as part of an agile, software-defined delivery mechanism.
To succeed, plan your SDN implementation with a ruthless "all or none" attitude.
F5 Networks helps organizations seamlessly scale cloud, data center, and software-defined networking deployments to successfully deliver applications to anyone, anywhere, at any time.