SDN’s Struggle to Summit the “Peak of Inflated Expectations”

SDN’s Vision

When Kaloom was founded, the assumptions that SDN and NFV would deliver programmability, automation, drive down costs and disrupt vendor lock-in had still not happened despite years of effort from the networking community.

While SDN promised the engineer’s dream of a truly programmable network, it initially enabled just a limited amount of additional software control and flexibility. Without programmability, the hardware could only perform the functions it was created with and networking would continue to lag behind the rapid advances made in other cloud technologies such as storage, compute and application development. So, whatever you were doing, or wanted to do, in software you couldn’t change what the non-programmable chip was capable of. This meant that the much-anticipated rapid innovation pace of software development and open source collaboration that were supposed to accelerate networking capabilities were still hamstrung by a years-long hardware product cycle.

Hamstrung by Hardware and Still Siloed

For example, the VXLAN network slicing specs were initially announced in 2011 and published in 2014 but the industry had to wait the intervening three years until the hardware that could support VXLAN was actually built.

“Siloed” solution stacks required service providers to continue purchasing products from the same incumbent vendor to centralize control and management of SDN deployments and ensure interoperability. Vendors were not interested in developing true open source, disruptive technologies that ran on inexpensive white box servers and switches because it threatened their existing revenues. No one was going to deliberately cannibalize their own business.

Incumbent networking vendors had to deliver some type of SDN solution because service providers were clamoring for them, and the competitive landscape was fierce. So, vendors built them, but they were tied to their proprietary “open” APIs. They were able to call them open because the API code was shared with the customer; however, this was not the same use of the word when compared to community-based organizations such as Linux, which are truly open and collaborative. If you used the API, then you were still tied to the vendors’ proprietary hardware and software solutions. In so doing, vendors found a way to keep service providers locked into their solution silos, enabling them to retain market share and protect their revenues while appearing to offer “open” SDN solutions. They were now getting revenue from both hardware and software sales – for a while.

To be fair to the large incumbent networking vendors, true open source network operating systems or a well-performing SDN controller were still in their early stages, with some controversy brewing surrounding their codes’ capabilities and founders’ intentions. For example, OpenDaylight was founded in 2013 and ended up being driven by vendors while the Open Network Operating System (ONOS) project was founded in 2012 and was driven by service providers. Although ONOS announced its launch first, OpenDaylight beat them to the punch with SDN controller code releases and initially seemed to have momentum on its side.

Open Source Evolution

Recent years have seen an entire ecosystem of truly open source, collaborative communities geared towards solving the challenges created by SDN’s initial vision. In fact, there are so many “.orgs” working on this that it can be confusing for service providers to decide which one to use to address each of its various needs. There are even several media articles that attempt to explain the foci and differences among them. Today, many of these have joined, merged, or collaborated with the IEEE, Open Networking Foundation (ONF), Apache, Linux and – in the case of Kubernetes – its Cloud Native Computing Foundation (CNCF), among others.

For our part, Kaloom and its staff are active with the IETF, ONF, the Open Compute Project (OCP), Linux and its LF Edge organization, Kubernetes, and the Broadband Forum. Because of the founders’ timing, many of these were initially designed and built on virtual machines (VMs) that preceded the introduction of Kubernetes which is now driving the adoption of open source container environments. VM-based solutions are not as lightweight, portable, or quick to instantiate as compared to containerized solutions so some projects are still hamstrung by their reliance on the heavier VM-based overlays and code. But that is a subject for another blog.

As of last year, Gartner stated that we are now entering SDN’s “Plateau of Productivity” on the analyst firm’s famous hype-cycle curve. Please come back next week to hear from our CEO about why we founded Kaloom, and how our solutions and choices work to solve many of the challenges initially posed by the vision of SDN and NFV.