Back at Interop Las Vegas 2012, software-defined networking was the talk of the town. In the weeks and months following Interop, we nattered nearly exclusively on the topic, debating its merits and potential pitfalls. SDN remains a hot topic and the technology has changed, although not exactly how some predicted.
My former colleague Mike Fratto’s prediction of the death of OpenFlow by 2014 turned out to be, as they say, exaggerated. However, his broader belief that SDN would evolve to focus more on management than programmable, white-box networking was pretty much spot on.
SDN proposed to change networking by introducing two programmable planes: control and data. A programmable control plane would standardize management of network devices while data plane programmability would enable new network services to be rapidly inserted into the network sans firmware upgrades. The control plane has become dominant, with a focus on the operational savings introduced by enabling a programmatic means of provisioning and configuring the network.
SDN has become a synonym for the economy of scale needed to ensure networks and their operational overlords are able to keep up with increasing demand driven by mobile apps, microservices architectures, and the almost ominous sounding Internet of Things. The focus of SDN now is not nearly as heavy on reducing investment dollars as it is on reducing time to market and operational costs.
Given the challenges faced by organizations today with respect to scaling networks to meet increasing demand both in volume and velocity, it’s no surprise that SDN has become as much an architectural solution to managing networks with an economy of scale on par with that of cloud computing. Many would, in fact, argue that SDN is simply an on-premise cloud computing implementation of network resources that abstracts the resources into services and leverages programmability (APIs) to enable greater agility in the foundational component of any data center.
Others (myself included) would similarly argue that SDN is a subset of DevOps, which emerged earlier than SDN, but which had not focused at all on the network until more recently. A DevOps focus of operational efficiency and time to market aligns well with the more programmatic methods of provisioning and configuration offered by more evolved SDN solutions.
To that end, we see network engineers and architects more interested in “DevOpsy” type characteristics when it comes to network equipment. Marketing stickers that label products as “DevOps” or “SDN” or even “cloud" are irrelevant. Rather, characteristics that support a more agile, software-defined data center are the new checkboxes on RFPs today: API-enablement, integration with popular frameworks like Puppet and Chef as well as Cisco and VMware, and support for treating network devices and services “as code.”
While the DevOps drumbeat of collaboration with Ops is on the radar, collaboration with Dev remains on the horizon. Silos built over years aren’t easily torn down, but the writing is on the wall as pressure increases on all IT operations (network, infrastructure, storage, and security) to “shift left” and become more integrated with the growing number of continuous efforts within the organization.
Regardless of whether you categorize SDN as a subset of DevOps, cloud or something all its own, the reality that is that SDN has become a means of achieving the scalability and efficiency required of modern networks to meet existing and future challenges associated with the application and API economy.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
