SDN focuses on connectivity challenges at layers 2 through 4 and largely ignores application-centric challenges at layers 4 to 7
This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
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:
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.
Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com
