Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part I)?

Javier Guillermo By Javier Guillermo June 27, 2018

The joke goes around that the true meaning of Software Defined Networking (SDN) is “Still Don’t Know.” SDN is a technology that allows network administrators to no longer be reliant on static architecture of traditional hardware/networks, but freed to centrally and dynamically manage the network via open, programmatic interfaces. This is accomplished by separating the control plane (the system that decides where the network traffic will go) from the data plane (the systems that forward the traffic onto their destination).

Introduction – The Journey

Although we can trace the origins of SDN to the early 2000s, we’ve just reached the decade mark when the creator of the controllers (Ethane) first released Openflow. In 2008, we saw the birth of NOX and the first Openflow Switches. Later on, we saw the entry of Nicira (acquired by VMware in 2012, now part of Dell Technologies), the creation of Google’s B4 project, and the Open Network Foundation (2011) and the development of ONOS.

He Said, She Said

Looking to the present, we see that with SDN, similar to many new emerging technologies of the past, seems to have developed two well-defined perspectives at opposite extremes. On one side, you have people who focus on the negative aspect and believe that SDN hasn’t lived up to the hype over the last decade. On the other side, you have folks who believe SDN will continue to grow and will explode in the 2020s, making bold predictions on market share and expansion rates[1].

But where is SDN really, now that a decade has gone by?

We all know that SDN is complicated, but is it an acronym for ‘Still Don’t Know?’

I believe we are somewhere in the middle of these two extreme perspectives. It’s true that we still have many experts claiming that NFV is not going to be good enough for high performance applications, that you will always have better performance on dedicated HW/SW. But then again, not everything that is going to be virtualized requires the absolute best performance and the priority is how easy it is to deploy, automate, reuse and its resulting CAPEX/OPEX savings.

On the SDN side, there were plenty of controllers five years ago and all efforts were being centered on Open Daylight (there are many commercial controllers based on this architecture, such as Floodlight, ONOS and NSX). The consolidation is good, but has it lived up to the hype that started in 2012-2013? Has it been massively adopted and implemented everywhere?

Not quite.

In the words of Diego Lopez, chair of ETSI NFV ISG[2] and a senior technology expert at Telefonica, “Perhaps we rushed to commercialize NFV (and SDN) before we laid down the proper foundations and principles for the technology. We can all agree that the initial timeframes given six years ago were too optimistic and will need to be more realistic in the future, and there are still numerous problems left to be solved.”

The main issue customers face with technology adoption is the lack of standardization, especially on the higher layers and interoperability. We’ve come a long way from just having SDN in research centers and academia at top tech universities, to several practical massive implementations in the “real world.”

#1 Deployment Example

The key deployment was spearheaded by Google[3], which manages one of the largest (if not the largest, with the permission of AWS) enterprise and cloud deployment in the world. It is no secret that Google has been a strong supporter of Open Daylight and Openflow, while continuing to encourage other controllers like ONOS. According to Amin Vahdat “the fundamental design philosophy was that the network should be treated as a large-scale distributed system, leveraging the same control infrastructure we developed.”

The company strategy is based on four pillars:

  1. Jupiter is a data center interconnect capable of supporting more than 100,000 servers and 1Pb/s of bandwidth.
  2. B4 WAN interconnect is Google’s implementation of SD-WAN[4] which constructs B4 to connect its data centers to one another and replicate data in real-time between individual campuses. “It’s built on white boxes with our software controlling it,” said Vahdat.
  3. Andromeda is a network functions virtualization (NFV) stack that delivers the same capabilities available to its native applications all the way to containers and virtual machines running on the Google Cloud Platform.
  4. Espresso, not the coffee (!), is the fourth and perhaps more challenging piece of the strategy. It extends SDN to the peering edge of Google’s network where it connects to other networks across the planet (Google exchanges data with ISPs at 70 metros and takes up to 25% of all internet traffic). The Espresso technology allows Google to dynamically choose from where to serve individual users based on measurements of how network connections are performing in real time. Espresso allows us to maintain performance and availability in a way that is not possible with existing router-centric Internet protocols, separating the logic and control of traffic management from the confines of individual network boxes. This translates to higher availability and better performance through Google Cloud than is available through the Internet at large.

Espresso improves user experience on two fronts: Firstly, it automatically selects the best data center location to server a specific tenant/user, based on real time statistics and formulas. Secondly, it separates the logic and traffic control from the individual routers, following the tenant of SDN of the separation of planes. A single distributed system with an aggregated vision of the overall network will always perform and make better decisions than an individual hardware router.


There is no clear agreement in the question ‘did SDN live up to the hype a decade later?’ Its adoption has been growing steadily but hasn’t replaced “traditional” networking yet. Once consolidation/ standardization and interoperability within the higher layers is achieved, its adoption may be unstoppable and major implementations like Google’s may become the norm.

Our team of expert Dell EMC Services consultants and advisers, as always, are here to answer your questions and advise a solution that best fits your needs.


[1] Software Defined Networking: Technology and Global Markets

[2] ETSI Standards

[3] Espresso makes Google cloud faster, more available and cost effective by extending SDN to the public internet

[4] SDxInsights on SD-WAN

Blog Series

Demystifying Software Defined Networking Part III: SDN via Overlays

Demystifying Software-Defined Networks Part II: SDN via APIs

Demystifying Software-Defined Networks Part I: Open SDN Approach


Javier Guillermo

About Javier Guillermo

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *

2 thoughts on “Demystifying Software-defined Networks: A Decade Later, Where Are We Now (Part I)?