Software-Defined Networking: The Next 5 Years

By Graham Robinson, Group Practice Manager – Data^#3

[Reading time: 4 mins]

The introduction of software and policy-driven infrastructure into enterprise IT brings with it an increasing reliance upon APIs for the configuration, monitoring, troubleshooting and integration of information services.

My previous post outlined how the once self-contained, monolithic networking products are being broken down into sets of smaller network services which communicate through application programming interfaces (API), and that the skills required by network engineers need to evolve… but when, and into what?

Over the last 15 years, network engineers have learned to deal with new challenges such as voice, video, fibre channel, wireless and countless new security technologies, however, the best is yet to come. The next five years will see networking break-free of its hardware prison, and realise its business value as companies rethink business operations and create new customer services – all powered by the network.

Like everything, the transition will be a journey; one likely to be marked by two distinct technology shifts, each fundamentally changing the daily responsibilities of a network engineer.

1st Horizon (2016-2020)

• There will be a marked decrease in the skills required to deploy a network, as basic configuration is no longer required to be done through the command line interface. Network hardware devices become plug and play with base configurations pushed down from centralised controllers (e.g. Cisco APIC-EM) where configuration policies have been created. These policies define which network services will operate (e.g. QoS, access, logging) and how they will interact with each other.
• The rise of new functionality to support IoT technology and provide increased security will see a new set of services embedded into corporate networks. Understanding APIs will allow network engineers to automate new network services, however many will choose to use traditional command line interfaces and fail to achieve the benefits promised by software-driven networks.
• The business will place increasing pressure on IT teams to deliver internal services with target service level agreements. In order to achieve the uptime, reliability and operational efficiency demanded by the business, the most efficient network engineers will look first to orchestration and automation software. APIs provide easy, consistent access into network functions. Custom in-house apps are the network engineer’s best friend, taking care of BAU activities for them.

2nd Horizon (2020+)

• The command line interface disappears from new products altogether. All configuration is done via centralised policies.
• API’s will be well understood, however, manual scripting is no longer required as integration between network APIs and application APIs is achieved through click-and-drag interfaces provided by Platform as a Service (PaaS) style offerings. These services are either on-premises, or more likely Cloud-based. Early example of these already exist (e.g. www.zapier.com).
• Business policies translate operational rules into network configurations, removing any need for companies to maintain network engineering skills to maintain infrastructure. New devices are auto-provisioned once connected to the network. Network services have become plug-and-play and installation requires only that someone know which cable plugs in where. Network management is outsourced cheaply to service providers operating at scale.
• Networks increasingly consistent of network micro-services, not network devices. Micro-services are stand-alone functions which run in a virtualised environment, such as VMware ESX. These individual services (e.g. Layer 3 routing, logging, access management, traffic shaping, etc.) can be installed, upgraded and restarted without impacting network operations. Furthermore, due to the virtualised nature of infrastructure, additional service instances can easily scale or be expanded to a N+N configuration for service resilience without significant effort.
• The adoption of policy-driven configuration means that policies are now critical. New policy-engines automatically translate from a set of operational rules to device-specific configuration.
• Although companies no longer need assistance with roll-outs and device configurations, companies rely upon those with the ability to clearly link business objectives to infrastructure services. An understanding of network services, application integration, data interchange and the system works together to deliver business outcomes becomes the cornerstone of a network engineer’s responsibilities.
• Consultants are engaged to map technical strategy to operational objectives, and then construct policies to meet the objectives. The success criteria for service engagements increasingly shifts from task-based outcomes to achieving operational KPIs which directly impact business operational (e.g. uptime, mean-time-to-restoration) or service success (e.g. customer satisfaction, revenue, etc.).

The network engineers that survive are those that choose to begin their journey now, slowly amassing software skills and a deeper understanding as to how their network services connect to business operations. By 2020, someone with the mentality of today’s network engineer will only be found in the most technologically antiquated organisations.

With such a significant change on the horizon, the next five years will fundamentally redefine what it means to be a network engineer as hardware, software and entire businesses become increasingly interdependent. See the next (and final) piece in this four-part series for advice on how to start your 5 year journey.

This is the third in a four-part series to help network engineers understand how software development will impact the enterprise network, and how augmenting their existing skills with even basic software development capabilities will help build more stable, secure and efficient networks to support business applications.