There is one really nice thing about having a blog whose readership consists mainly of car insurance spambots: I don’t have to feel guilty when I don’t post anything for a while. I had started a series on programmability, but I managed to get sidetracked by the inevitable runup to Cisco Live that consumes Cisco TME’s, and so that thread got a bit neglected.
Meanwhile, an old article by the great Ivan Pepelnjak got me out of post-CL recuperation and back onto the blog. Ivan’s article talks about how vendor lock-in is inevitable. Thank you, Ivan. Allow me to go further, and write a paean in praise of vendor lock-in. Now this might seem predicable given that I work at Cisco, and previously worked at Juniper. Of course, lock-in is very good for the vendor who gets the lock. However, I also spent many years in IT, and also worked at a partner, and I can say from experience that I prefer to manage single vendor networks. At least, as single vendor as is possible in a modern network. Two stories will help to illustrate this.
In my first full-fledged network engineer job, I managed the network for a large metropolitan newspaper (back when such a thing existed.) The previous network team had installed a bunch of Foundry gear. They also had a fair amount of Cisco. It was all first generation, and the network was totally unstable. Foundry actually had some decent hardware, but their early focus was IP. We were running a typical 1990’s multi-protocol network, with AppleTalk, IPX, SNA, and a few other things thrown in. The AppleTalk/IPX stack on the Foundry was particularly bad, and when it interacted with Cisco devices we had a real mess.
We ended up tossing the Foundry and going 100% Cisco. We managed to stabilize the network, and now we were dealing with a single vendor instead of two. This made support and maintenance contract management far easier.
Second story: When I worked for the partner, I had to do a complete retrofit of the network for a small school district. They had a ton of old HP, and were upgrading their PBX to a Cisco VoIP solution. This was in the late 2000’s. I did the data network, and my partner did the voice setup. The customer didn’t have enough money to replace all their switches, so a couple of classrooms were left with HP.
Well, guess what. In all the Cisco-based rooms, I plugged in the phones and they came up fine. The computers hanging off the internal phone switch port also came up fine, on the correct data VLAN. But on the classrooms with the HP switches, I spent hours trying to get the phones and switches working together.
There is a point here which is obvious, but needs restating. If Cisco makes the switches, the routers, the firewalls, and the phones, the chances of them all working together is much higher than if several vendors are in the mix. Even with Cisco’s internal BU structure, it is far easier to call a meeting with different departments within a company than to fix problems that occur between vendors. Working on Software Defined-Access, I learned very quickly how well we can pull together a team from different product groups, since our product involves switching (my BU), ISE, wireless, and APIC-EM.
As I mentioned above, the other advantage is easier management of the non-technical side of things. Managing support contracts, and simply having one throat to choke when things go wrong are big advantages of a single-vendor environment.
All this being said, from a programmability perspective we are committed to open standards. We realize that many customers want a multi-vendor environment and tools like OpenConfig with which to manage it. Despite Cisco’s reputation, we’re here to make our customers happy and not force them into anything. From my point of view, however, if I ever go back to managing a network I hope it is a single-vendor network and not a Fraken-network.
Meanwhile, if you’d like to hear my podcast with Ivan, click here.