Summary Bullets:
- The main benefit from SDN is that managing devices via the CLI will come to an end.
- Putting the final nail in the CLI coffin will require vendors and administrators to think differently.
Whenever I talk to Arista Networks’ Doug Gourlay, I always ask when the company is going to make a GUI manager for their networking gear. It’s something of a running joke, because Arista doesn’t have one, preferring to focus on making its products integrate with others; let someone else make a GUI manager. Other vendors such as Alcatel-Lucent, Avaya, Brocade, Cisco, Dell, Extreme, HP, IBM and Juniper have a similar strategy, which is to make their switch products controllable via APIs and make their network managers capable of much more robust command and control processes.
The CLI has hung around so long because the alternatives – such as SNMP, writing CLI shell scripts or, worse, moving entire configuration files around – are half baked, unreliable and disruptive. Network administrators could telnet to a switch, punch in a few commands and ensure the switch or router is properly configured. Little cottage industries developed to make CLI management easier, such as automating the replication of common command sets, managers that tried to maintain configuration histories and communities that shared scripts for common or not so common tasks.
If nothing else comes out of SDN, it will be that the CLI will die a fiery death.
Network management systems all tried to aggregate devices such as switches, routers, firewalls, etc. into a uniform fabric, but the management UIs quickly broke down into element managers breaking the fabric paradigm and being reduced to multi-unit management. SDN structures such as APIs are simply fancy element managers using a different method, but what changes is that a controller – nearly all SDN architectures use some type of controller – becomes the aggregation point; network administrators will express what they want via a policy and the controller will, to quote Star Trek: The Next Generation’s Jean-Luc Picard, “Make it so.”
If IT is deploying an N-tier application, administrators will not access devices via a CLI or GUI and make changes; they will tell the controller, “I have three application tiers and I need these services between them. I also need each tier to scale on demand. I need this kind of firewall policy, and any traffic leaving this location needs to be encrypted.” When the application changes, IT will describe the changes and let the controller figure out what needs to be done. Finally, when the application is no longer needed, the controller will clean up after itself. It doesn’t matter if the network is physical or virtual, whether you’re using Ethernet, OpenFlow or an overlay. More importantly, when there’s a problem, the controller will provide the instrumentation to assist in troubleshooting and resolving the problem through modeling and automation data gathering.
Of course, the death of the CLI depends heavily on network and network management vendors adopting new management paradigms that effectively abstract the details from administrators. It will also require network administrators giving up manual processes and trusting the controller. It won’t happen overnight, but it will happen. That’s the hope, anyway.
IT Connection 
[Disclaimer: Not a network expert at all] Nice post, I was thinking, in this case wont the CLI move up to the controller? I mean a CLI is also used as another way to do the GUI tasks and therefore tasks like defining policies etc will also need a CLI. And what are your thoughts on diagnoses ? Will CLIs not be needed to work out where things are going wrong with the policies that have been configured? It sounds to me like this is automated network heaven and it will certainly take a long time for SDN to progress to this level of automation but yeah, it makes sense and will be very cool when it happens!