I was doing well on the blog for a few months but lately fell behind. With (now) 12 people reporting to me, and three major areas of responsibility (SD-Access, Assurance, and Programmability), it’s not easy to find time to write up a blog post. I have about five drafts needing work but I cannot seem to find the will to finish them. Sometimes, however, it just takes a spark to get me going. That spark came in my inbox from Ivan Peplnjak. I like Ivan’s blog posts, which, while often not favorable to Cisco, are nonetheless fair and balanced and raise some very important points.
“Why Is Every SDN Vendor Bashing Networking Engineers?” asks Ivan in the form email I received. “[T]he vendors know they wouldn’t be able to sell their latest concoctions to people who actually understand how networking works and why some architectures have no chance of ever working in real life,” answers Ivan. “The only way to sell the warez is to try to convince everyone else how to get rid of the pesky ossified CLI jockeys.”
Now I work for a vendor, and since I deal with the aforementioned products, I guess I am an SDN vendor. That would seem to qualify me to speak on this subject. (With, of course, the usual disclaimer that the opinions here are my own and do not represent Cisco officially.)
Selling Concoctions
I must admit, I do want to sell our products. Everyone at Cisco should want our products to sell. Just about all of us have a personal, financial stake in the matter, whether we have stock grants or ESPP. We would be insane not to want people to buy our products. I, and most of my co-workers, are driven by far more than finance, however. We all want to know that our work means something, and that we are coming up with innovative solutions to problems. Otherwise, why show up in the office every day?
We operate in a highly competitive environment, which means if we are not constantly innovating and coming up with better ways to do things, we will all suffer. You can complain about the macroeconomic system, and believe me, I’m not a Randian, objectivist believer in unbridled capitalism. But, at the end of the day, a public company needs to create the perception of future value in the eyes of the stock market, and that’s a motivating factor for all of us.
These things being said, I’ve been in product management for a few years now and I have never heard anyone, ever, talk about trying to put one over on our customers. I’m not saying that’s what Ivan means here, but it’s an accusation I’ve heard before. In the first place, our customers are network engineers who are quite smart. If ever I’ve presented to my customer and was not crystal clear on what I was talking about and what advantage it would bring the customer, they will let me know it. We’re constantly trying to find ways to do things better and make our customers’ lives easier. As somebody who worked in IT for more years than product management, I’m very interested in this subject. There were a lot of things that were frustrating and I want to fix things that used to annoy me. You can argue about whether we’ve come up with the right ideas, but I hope nobody questions our motivations.
CLI Jockeys
Do I bash CLI jockeys in order to sell my products? I should hope not, given that most of my customers are CLI jockeys, as I am myself! I have two CCIEs and a JNCIE. I spent a couple years in routing protocols TAC and many years in IT. I spent a long time learning my trade and I have a lot of respect for those who have put the time and effort into learning it as well. It’s not easy.
However, I don’t operate under the delusion that network engineers do a good job of configuring and managing CLI. When I was at Juniper, I had designed a new NGMVPN system for our WAN. I handed it off to the implementation team with some sample configs and asked them to come back to me with their plan. I think we were touching about 20 devices the first go around. The engineer came back with 20 Word documents. He took my sample config and copied and pasted it into Word, and then modified the config in a separate Word doc for each CE/PE he was touching. CLI itself isn’t a problem, but how we manage it. This is where programmability and automation tools come in. At the very least Ansible templating would have made this easier. Software-Defined Networking (a very loose term, for what it’s worth), is not about replacing ossified CLI jockeys but getting them to focus on what they should be doing (network engineering) and avoiding what they should not (pasting stuff in Word docs.)
SD-Access takes this quite a bit further than Ansible, NETCONF, and other device-level tools. Rather than saying “I want this device to be a LISP MS/MR” and so forth, you just say “I want this device to be a control plane node” and the system figures out what you need. Theoretically we could change from LISP to some other protocol and the end-user shouldn’t even notice. The idea here is somewhat like a fly-by-wire system. When a pilot operated the controls of an airplane, they used to be directly coupled to the control surfaces via hydraulics. Now, the pilot is operating what is essentially a joystick, providing control inputs to a computer, which then computes the best way to move the control surfaces given the conditions. This is then relayed to servo motors in the wings, tail, etc. The complexity of a fly-by-wire system is much higher than an old hydraulic system, but the complexity is hidden from the pilot in order to provide a better experience. Likewise, with SD-Access, we’ve made the details more complex in order to deliver a better experience (TrustSec, layer 3 routed backbone, etc.) while hiding the complexity from the user. It’s a different approach, for sure, but the idea is to allow engineers to focus on the right problems, like how to design their network, and not worry so much about configuration.
A New Era?
I’ve written extensively (see, for example, here, and here) about the role for CLI-jockey network engineers in the future. When airplanes switched from the old dials and gauges to sleek, modern computerized (glass) cockpits, I’m sure some old timers threw up their hands, retired, and got their old Piper Super Cubs out of the hanger to do some “real” flying. But most adapted, and in the end, saw how the new automation systems helped them do their jobs better. That’s an era I’m looking forward to. And as I always, always say, the pilots who fly the new cockpits still need to understand weather systems, engines, navigation, etc. We still need network engineers who know how networks operate.
Meanwhile, I won’t bash any CLI jockeys and I hope nobody else here does either.