Will software-defined networking kill network engineers' beloved CLI?

Networks defined by software may require more coding than command lines, leading to changes on the job

Cisco Chief Strategy and Technology Officer Padmasree Warrior spoke on Wednesday at a press event at Cisco.

Cisco Chief Strategy and Technology Officer Padmasree Warrior spoke on Wednesday at a press event at Cisco.

SDN (software-defined networking) promises some real benefits for people who use networks, but to the engineers who manage them, it may represent the end of an era.

Ever since Cisco made its first routers in the 1980s, most network engineers have relied on a CLI (command-line interface) to configure, manage and troubleshoot everything from small-office LANs to wide-area carrier networks. Cisco's isn't the only CLI, but on the strength of the company's domination of networking, it has become a de facto standard in the industry, closely emulated by other vendors.

As such, it's been a ticket to career advancement for countless network experts, especially those certified as CCNAs (Cisco Certified Network Associates). Those network management experts, along with higher level CCIEs (Cisco Certified Internetwork Experts) and holders of other official Cisco credentials, make up a trained workforce of more than 2 million, according to the company.

A CLI is simply a way to interact with software by typing in lines of commands, as PC users did in the days of DOS. With the Cisco CLI and those that followed in its footsteps, engineers typically set up and manage networks by issuing commands to individual pieces of gear, such as routers and switches.

SDN, and the broader trend of network automation, uses a higher layer of software to control networks in a more abstract way. Whether through OpenFlow, Cisco's ONE (Open Network Environment) architecture, or other frameworks, the new systems separate the so-called control plane of the network from the forwarding plane, which is made up of the equipment that pushes packets. Engineers managing the network interact with applications, not ports.

"The network used to be programmed through what we call CLIs, or command-line interfaces. We're now changing that to create programmatic interfaces," Cisco Chief Strategy Officer Padmasree Warrior said at a press event earlier this year.

Will SDN spell doom for the tool that network engineers have used throughout their careers?

"If done properly, yes, it should kill the CLI. Which scares the living daylights out of the vast majority of CCIEs," Gartner analyst Joe Skorupa said. "Certainly all of those who define their worth in their job as around the fact that they understand the most obscure Cisco CLI commands for configuring some corner-case BGP4 (Border Gateway Protocol 4) parameter."

At some of the enterprises that Gartner talks to, the backlash from some network engineers has already begun, according to Skorupa.

"We're already seeing that group of CCIEs doing everything they can to try and prevent SDN from being deployed in their companies," Skorupa said. Some companies have deliberately left such employees out of their evaluations of SDN, he said.

Not everyone thinks the CLI's days are numbered. SDN doesn't go deep enough to analyze and fix every flaw in a network, said Alan Mimms, a senior architect at F5 Networks.

"It's not obsolete by any definition," Mimms said. He compared SDN to driving a car and CLI to getting under the hood and working on it. For example, for any given set of ACLs (access control lists) there are almost always problems for some applications that surface only after the ACLs have been configured and used, he said. A network engineer will still have to use CLI to diagnose and solve those problems.

However, SDN will cut into the use of CLI for more routine tasks, Mimms said. Network engineers who know only CLI will end up like manual laborers whose jobs are replaced by automation. It's likely that some network jobs will be eliminated, he said.

This isn't the first time an alternative has risen up to challenge the CLI, said Walter Miron, a director of technology strategy at Canadian service provider Telus. There have been graphical user interfaces to manage networks for years, he said, though they haven't always had a warm welcome. "Engineers will always gravitate toward a CLI when it's available," Miron said.

Even networking startups need to offer a Cisco CLI so their customers' engineers will know how to manage their products, said Carl Moberg, vice president of technology at Tail-F Systems. Since 2005, Tail-F has been one of the companies going up against the prevailing order.

It started by introducing ConfD, a graphical tool for configuring network devices, which Cisco and other major vendors included with their gear, according to Moberg. Later the company added NCS (Network Control System), a software platform for managing the network as a whole. To maintain interoperability, NCS has interfaces to Cisco's CLI and other vendors' management systems.

CLIs have their roots in the very foundations of the Internet, according to Moberg. The approach of the Internet Engineering Task Force, which oversees IP (Internet Protocol) has always been to find pragmatic solutions to defined problems, he said. This detailed-oriented "bottom up" orientation was different from the way cellular networks were designed. The 3GPP, which developed the GSM standard used by most cell carriers, crafted its entire architecture at once, he said.

The IETF's approach lent itself to manual, device-by-device administration, Moberg said. But as networks got more complex, that technique ran into limitations. Changes to networks are now more frequent and complex, so there's more room for human error and the cost of mistakes is higher, he said.

"Even the most hardcore Cisco engineers are sick and tired of typing the same commands over and over again and failing every 50th time," Moberg said. Though the CLI will live on, it will become a specialist tool for debugging in extreme situations, he said.

"There'll always be some level of CLI," said Bill Hanna, vice president of technical services at University of Pittsburgh Medical Center. At the launch earlier this year of Nuage Networks' SDN system, called Virtualized Services Platform, Hanna said he hoped SDN would replace the CLI. The number of lines of code involved in a system like VSP is "scary," he said.

On a network fabric with 100,000 ports, it would take all day just to scroll through a list of the ports, said Vijay Gill, a general manager at Microsoft, on a panel discussion at the GigaOm Structure conference earlier this year.

"The scale of systems is becoming so large that you can't actually do anything by hand," Gill said. Instead, administrators now have to operate on software code that then expands out to give commands to those ports, he said.

Faced with these changes, most network administrators will fall into three groups, Gartner's Skorupa said.

The first group will "get it" and welcome not having to troubleshoot routers in the middle of the night. They would rather work with other IT and business managers to address broader enterprise issues, Skorupa said. The second group won't be ready at first but will advance their skills and eventually find a place in the new landscape.

The third group will never get it, Skorupa said. They'll face the same fate as telecommunications administrators who relied for their jobs on knowing obscure commands on TDM (time-division multiplexing) phone systems, he said. Those engineers got cut out when circuit-switched voice shifted over to VoIP (voice over Internet Protocol) and went onto the LAN.

"All of that knowledge that you had amassed over decades of employment got written to zero," Skorupa said. For IP network engineers who resist change, there will be a cruel irony: "SDN will do to them what they did to the guys who managed the old TDM voice systems."

But SDN won't spell job losses, at least not for those CLI jockeys who are willing to broaden their horizons, said analyst Zeus Kerravala of ZK Research.

"The role of the network engineer, I don't think, has ever been more important," Kerravala said. "Cloud computing and mobile computing are network-centric compute models."

Data centers may require just as many people, but with virtualization, the sharply defined roles of network, server and storage engineer are blurring, he said. Each will have to understand the increasingly interdependent parts.

The first step in keeping ahead of the curve, observers say, may be to learn programming.

"The people who used to use CLI will have to learn scripting and maybe higher-level languages to program the network, or at least to optimize the network," said Pascale Vicat-Blanc, founder and CEO of application-defined networking startup Lyatiss, during the Structure panel.

Microsoft's Gill suggested network engineers learn languages such as Python, C# and PowerShell.

For Facebook, which takes a more hands-on approach to its infrastructure than do most enterprises, that future is now.

"If you look at the Facebook network engineering team, pretty much everybody's writing code as well," said Najam Ahmad, Facebook's director of technical operations for infrastructure.

Network engineers historically have used CLIs because that's all they were given, Ahmad said. "I think we're underestimating their ability. "

Cisco is now gearing up to help its certified workforce meet the newly emerging requirements, said Tejas Vashi, director of product management for Learning@Cisco, which oversees education, testing and certification of Cisco engineers.

With software automation, the CLI won't go away, but many network functions will be carried out through applications rather than manual configuration, Vashi said. As a result, network designers, network engineers and support engineers all will see their jobs change, and there will be a new role added to the mix, he said.

In the new world, network designers will determine network requirements and how to fulfill them, then use that knowledge to define the specifications for network applications. Writing those applications will fall to a new type of network staffer, which Learning@Cisco calls the software automation developer. These developers will have background knowledge about networking along with skills in common programming languages such as Java, Python, and C, said product manager Antonella Como. After the software is written, network engineers and support engineers will install and troubleshoot it.

"All these people need to somewhat evolve their skills," Vashi said. Cisco plans to introduce a new certification involving software automation, but it hasn't announced when.

Despite the changes brewing in networks and jobs, the larger lessons of all those years typing in commands will still pay off for those who can evolve beyond the CLI, Vashi and others said.

"You've got to understand the fundamentals," Vashi said. "If you don't know how the network infrastructure works, you could have all the background in software automation, and you don't know what you're doing on the network side."

Stephen Lawson covers mobile, storage and networking technologies for The IDG News Service. Follow Stephen on Twitter at @sdlawsonmedia. Stephen's e-mail address is stephen_lawson@idg.com

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags careersIT managementMicrosofttrainingbusiness issuesNetworkingsoftwarepersonnelstaff managementCisco SystemsLyatissNuage Networks

More about BillCiscoF5F5 NetworksFacebookGartnerGatewayGatewayIDGIETFInternet Engineering Task ForceLANLawsonMicrosoftTelus

Show Comments
[]