A common theme that I have heard and read recently is that network engineers are a significant obstacle to getting things done (or in less polite terms that us "CLI-jockeys" stink and it takes us way too long to configure a stupid VLAN)

Bob McCouch talks about part of this issue in a recent blog post, "Those Slow Poke Network Engineers". In part of this article Bob states:

The lack of automation and tools force very manual workflows compared to virtual server technologies that basically instantiate a new server in seconds. This is a legitimate gripe considering the impact of server virtualization in terms of new application provisioning. It’s absolutely fair to say that it may take somewhat longer to get a new VLAN, routed interface, firewall zone, and load-balancer context created end-to-end than it does to start booting the new virtual servers that will go in it.

While Bob's article talks about network engineers having too much work, supporting many different parts of an organization, and the inherent dependency of many things on the network, I want to focus on the aspect of tools. Namely, why don't we have a better set of tools in our tool belt? The server team has Python, Ruby, Puppet, Chef, Ansible, Cobbler, Fabric to name just a few. We on the other hand are like people scavenging the leftovers at a dinner party (what was that SNMP OID again). Where is our next generation of tools? Yes, I know some vendors have added very limited support for Puppet, Chef, and Ansible.

So why don't network engineers have better network management tools? We don't have better tools and more rapid tool innovation because historically innovation has largely been controlled by the hardware vendors (and correspondingly the market has not required through purchasing choices a better solution). Individuals and companies building tools have been stuck using the protocols provided by the hardware vendors (SNMP, NETCONF, SSH/telnet) and because there is no common open platform you really cannot build your own communication method directly into the network devices (by open platform I mean a platform where essentially all parts of the system can be changed by anyone). The historical flow has been hardware vendors decide what management protocols to build (possibly in a standardization process), implement them, and then we live with them. This is very different to the Linux world

In Linux, if I don't have something I can find it and install it (or if push comes to shove create it myself). This includes essentially every part of the system including modifying the kernel (Facebook modified the kernel to get NetFlow data from their servers), but I can't do this in the networking world. In the networking world I generally can't get on a router and start importing python modules and compile a new application. I can't build a new protocol if I am unhappy with SNMP or not keen on using NETCONF.

But, thankfully, network management is changing. This change is being driven by several larger trends—1)Cloud computings expansion into networking i.e. the virtualization of network services, 2)SDN (by SDN I am referring here specifically to the centralization of the control plane), 3)DevOps coming to networking, and 4)Linux/white box switches. The rise of SDN (and cloud computing APIs—AWS, OpenStack) has scared hardware vendors (well Cisco anyways) to react and to create APIs into their equipment (or with OpenDaylight a multi-vendor API on a centralized controller). The success of developer/server teams and the interest in applying DevOps to networking has also pushed hardware vendors to integrate with Puppet, Chef, and Ansible albeit with very limited capabilities currently. Finally companies and other organizations (Cumulus Networks, Open Compute) are working on separating hardware from software, especially with switches, to create significantly more open platforms.

Which methods will gain widespread acceptance; which methods will fall flat—we shall see. But whichever methods win there should be much more innovation in network management. There will be significantly more ways to programmatically manage the network and there will be a much broader set of individuals that can now innovate in this space.