@CloudExpo Authors: Zakia Bouachraoui, Liz McMillan, Pat Romanski, Yeshim Deniz, Elizabeth White

Related Topics: @CloudExpo, Java IoT, Microservices Expo, Containers Expo Blog, Machine Learning , Apache, Cloud Security, @DXWorldExpo

@CloudExpo: Blog Feed Post

SDN: Concrete or Concept?

Is SDN a concept, or a concrete architectural construct? Does it really matter?

Now, if we look at the benefits we can attempt to infer what the problems SDN is trying to solve:



Programmability Network components today, particularly hardware-based components, run specific feature sets that can only be modified by the vendor, which happens on a 12-18 month schedule, security and hot-fixes not withstanding. New features and functions can only be added by the vendor based on their prioritization, not the customer.
Automation Manual configuration of network components is time consuming, costly, and introduces a higher risk of human error that can result in outages, poor performance, or security risks.
Network control The network today doesn't adapt rapidly to changing conditions or events. While some protocols simulate such adaptability, these protocols can't autonomously route around outages or failures or modify existing policies easily.

These are certainly problems for IT organizations of a variety of sizes and composition. The question then is, how does SDN uniquely solve those problems?

The answer is that as a concrete solution (i.e. components, software, and architectures)  it does not uniquely solve the problem. As a concept, however, it does.

Someone's no doubt quite upset at the moment at that statement. Let's explain it before someone's head explodes.


The concept of separating data and control plane enables programmability. Without that separation, we have what we have today – static, inflexible networking components. But the concept of separating data and control planes isn't unique to solutions labeled specifically SDN. ADN is a good example of this (you saw that coming, didn't you?)

A network component can – and this may surprise some people – internally decouple control and data planes. Yeah, I know, right? And doing so enables a platform that looks a whole lot like SDN diagrams, doesn't it – with plug-ins and programmability. This occurs in full-proxy architectures when there exist dual stacks – one on the client side, one on the server side. Where traffic transitions from one stack to the other exists an opportunity to inspect, to manipulate, to modify, the traffic. Because the architecture requires acting as an endpoint to clients (and conversely as the point of origin for the server side), protocols can even be implemented in this "no man's land" between client and server. That enables protocol transitioning, such as enabling SPDY on the outside while still speaking HTTP on the inside or IPv4 to servers while supporting IPv6 on the client (and vice-versa).

Where the separation occurs is not necessarily as important as the fact that it exists – unless you're focused on concrete, SDN-labeled solutions as being the only solutions that can provide the flexibility that programmability offers.

Automation occurs by exposing the management plane through an API (or implementing a specific API, such as OpenFlow) such that operational tasks and configuration can be achieved through tools instead of time.

Between automation and programmability, you realize network control.

Now, this is not SDN, at least not in terms of protocol support and concrete architecture. But it is software-defined, and it is networking, so does it count?

I guess it depends. ADN has always approached layers 4-7 with an eye toward extensibility, programmability and control that enables agility in the network. We didn't call it SDN and I don't see the industry deciding to "SDN-wash" existing ADN solutions as SDN just because a new term came along and became the TLA du jour.

What I do see is that ADN and specifically full-proxy based ADC (application delivery controllers) already offer the same benefits using the same concepts as SDN. Consider again the core characteristics of SDN:

1. Control and data planes are decoupled

2. Intelligence and state are logically centralized

3. Underlying network infrastructure abstracted from applications

All of these characteristics are present in an ADN. The ability to leverage network-side scripting on the control plane side of the equation enables extensibility, rapid innovation, and ability to adapt to support new protocols, new applications, new business requirements – all without involving the vendor. Which is exactly one of the benefits cited for SDN solutions and specifically OpenFlow-enabled architectures.

So the question really is, does it matter if a solution to the problem of "agility in the network" is a concrete or conceptual SDN solution if it ultimately solves the same set of problems?

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the public cloud best suits your organization, and what the future holds for operations and infrastructure engineers in a post-container world. Is a serverless world inevitable?
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Machine learning provides predictive models which a business can apply in countless ways to better understand its customers and operations. Since machine learning was first developed with flat, tabular data in mind, it is still not widely understood: when does it make sense to use graph databases and machine learning in combination? This talk tackles the question from two ends: classifying predictive analytics methods and assessing graph database attributes. It also examines the ongoing lifecycle for machine learning in production. From this analysis it builds a framework for seeing where machine learning on a graph can be advantageous.'