(Apologies to Pete Seeger for borrowing his poignant and powerful song. The lyrics just felt apropos to this post. Regardless, his anti-war anthem is important and always pertinent.)

Yes, “SDN controllers” is far too many syllables to be sung, but just bear with me. The Linux Foundation’s Open Networking Summit (ONS) will be held next week in San Jose, California, and for many technology analysts it’ll be our third trek in four weeks to the McEnery Convention Center (OCP Summit, nVidia’s GTC, and now ONS). There’s going to be a good amount of ONAP – 11 presentations – and even more edge — 21 presentations – but there’s one previously hot item that will not be discussed much: SDN controllers.

In the early days of ONS, both before the Linux Foundation took over running ONS and soon after, it used to be the place where SDN controllers were discussed, even lauded. OpenFlow, SDN, and SDN controllers featured prominently, while this year’s conference appears to only have three presentations on controllers: one on OpenDaylight and containers; another on OpenDaylight in transport networks; and finally one on the Faucet controller in a high-speed multi-terabit network. And this despite the recent release of OpenDaylight’s latest update, dubbed Neon.

Good old NOX, POX, Beacon, Floodlight, Trema, Ryu and their siblings have dropped from the limelight. Even OpenDaylight and ONOS are no longer the hottest topics at most networking shows.

What Happened to the SDN Controller? Long Time Passing

Indeed, that’s a question that has come up in recent conversations with colleagues about the upcoming ONS conference. In a recent post on SDN, I discussed the lack of visibility around SDN, even though the fundamental principles are embedded in our very infrastructure.

Just two years ago, OpenDaylight was a major Linux Foundation project with significant momentum. It had more than 2,000 contributors, 5,000 members in the global community, and it was lauded in a quote from Dave Ward of Cisco: “OpenDaylight fundamentally changed the Linux Foundation’s world. It’s been wildly successful. It’s the de facto standard open source SDN controller for the industry today.” Multiple corporations supported it, and there were promising commercial versions of it. And it wasn’t the only hot SDN controller. ON.Lab, which eventually became ONF, was seeing traction with its ONOS platform, particularly from the WAN market. And Juniper was trying to push the OpenContrail platform, now called Tungsten Fabric.

In fact, Brocade, powered by OpenDaylight, made a huge run at the SDN market, investing a significant amount into SDN while trying to transition away from being just a storage player. They hired prominent open-source controller developers and led OpenDaylight development efforts. However, revenue capture proved difficult in the SDN controller market. Eventually, Brocade’s acquisition by Broadcom resulted in their open-source efforts being broken up and sold or spun off, with Vyatta going to AT&T and the controller spinning out as Lumina Networks.

Demise of the SDN App Economy, a Long Time Ago

Back then there were plenty of diagrams that depicted the SDN controller as an overarching network platform. It was supposed to provide control over all network elements and be the one uber-platform on which networking applications would run: routing, security, and more. Remember Hewlett Packard Enterprise’s App Store? We all thought that networking would be transformed to an app economy, with the SDN controller becoming the equivalent of the Android and iOS platform on which network apps would be written.

That hasn’t quite happened. Instead, we are faced with the integration of SDN controllers and elements into orchestration or more single-function applications. For example, SD-WAN solutions have a controller, but it’s not exposed except through SD-WAN-specific APIs. And network virtualization in the form of Cisco ACI, VMware NSX, Nuage Networks VSP, and Juniper Contrail have embedded SDN controllers, but you can’t run third-party apps on top of these controllers – at least not today. There are also applications in optical transport networks for which networking controllers exist, but again, we lack a networking application ecosystem.

When Will They (We) Ever Learn?

Today, on the pure SDN controller front, we have Lumina Networks continuing to be the standard bearer of the movement. Unfortunately, the other second-generation SDN controller company focused on OpenDaylight, Inocybe, was acquired by Kontron, which has since moved off an OpenDaylight-centric strategy. There are still a few open-source SDN controller companies out there, like Frinx, who are building custom solutions for China Telecom and SoftBank. However, there’s no commercial SDN controller company at scale we can point to, like a Red Hat for Linux. In fact, Red Hat itself has apparently stopped work on creating a commercially-supported distribution of OpenDaylight.

As many of us head to ONS 2019 next week, it’s important to remember that platforms will come and go based on their fit for real-world problems. If there isn’t a strong fit, or if the problem isn’t sufficiently compelling or urgent enough to drive change, the platform will not succeed. And a collection of little niggling issues like networking equipment not being uniform in their ability to be controlled by SDN, a lack of ability to quickly develop and integrate standard APIs into networking equipment, or a lack of sustainable business model can eventually prove fatal in a death by a thousand cuts. Again, it’s not that SDN is dead, but that a business predicated just on selling an SDN controller is hard to sustain.

Let’s make sure that our eyes stay wide open at ONS as we preview the next hot platforms on which to build our businesses, and make sure that we’ve actually learned from the last round.

Photo attribution: Ornella Binni from Unsplash