In today’s IT infrastructure, open source software is a common component. Many organizations and network engineers stay away from certain architectures and products citing vendor lock-in as their only argument but often lack the understanding to why they think vendor lock-in is a problem. Let me explain.
There are lock-ins of different forms. For example if you are buying MPLS VPN service from a SP, you are somewhat locked in to their offering and pricing. I see at least three types of different lock-in:
Vendor lock-in – This is the one that everyone is familiar in. It means that the vendor has a solution that is proprietary, perhaps using proprietary management or routing protocols so that it can’t interact with solutions from other vendors.
Tools lock-in – This may or may not be as much of a lock-in as vendor lock-in, but when an organization has invested enough time, money and manpower into a specific toolset, it’s difficult to move to other tooling.
People lock-in – An often oversighted form of lock-in. Depending on architecture, toolset and so on, your organization may need a certain type of engineers to work on the network. These may be difficult to find which leaves you vulnerable if certain key people leave the company.
So before we move on to discuss vendor lock-in in more detail, let us look more closely at the other two. I have seen examples where a very critical piece of software was written by one person where it started out as probably a small project to improve upon something and where it ended up being a critical piece of software that the entire organization, and people’s lives were dependent upon. This person then retired and was brought in as a consultant to help with the software. This is a very dangerous form of lock-in because while you can replace a vendor, it’s more difficult to replace people. Your organization may have ambitious engineers right now with the right skillset, but what happens when they go somewhere else? You need to have a plan for this. How do you train others? Are you willing to pay market compensation for these people that are in demand? Are you properly documenting your designs and implementations?
There can also be lock-in in the form of different toolsets. While it’s certainly possible to move to other tools, the organization might have reached a point where they are so invested in a toolset, that if they were to change, it would require such a massive effort that they don’t see how they are to supposed to succeed with the transition. This could happen even when using open source tools. Maybe the tools weren’t as ready as you expected or didn’t cover your specific use cases. This means you need to put time and money into developing them. Maybe you hit a point where you realize that you made the wrong choice. You should have gone with another tool. How do you recover from this situation? So while there is nothing from a technical perspective keeping you from changing, there may business reasons that are you stopping you such as lack of time, people and money.
Let us then discuss vendor lock-in. Let’s say that your organization decides to use Cisco’s Application Centric Infrastructure (ACI) architecture. ACI is a Cisco proprietary solution that uses VXLAN, BGP, ISIS and COOP. Several of these protocols are standards but it’s still a proprietary solution. Some organizations will not consider something like ACI because it’s proprietary. That’s a perfectly valid choice but what is your motivation for doing so? While the ACI fabric is proprietary, does it require proprietary servers? Does it use special protocols towards the servers? Can it interact with other devices? Using ACI you can use any form of server and it’s still Ethernet towards the end hosts unless you run for example VXLAN. ACI supports extending both L2 and L3 out of the fabric and can therefore support both extending VLANs or running OSPF and BGP towards other parts of the network. So yes, ACI is a black box but it’s one that doesn’t necessarily affect the rest of your network. So how difficult is it then to replace it? Not that difficult. Sure, migrations are always a pain but there is nothing from a technical standpoint preventing you from doing it.
Vendor lock-in is not therefore in itself inherently a business problem unless it is preventing the business from performing what is expected. It may be a culture problem but that’s something different.
What’s more dangerous from a technical standpoint is solutions that can’t interact at all with other vendors and that requires specialized hardware at your end hosts. As long as your end hosts can be whatever you want, you can change the networking components by for example having a new part of the network with another vendor and then migrate end hosts to the new network.
I hope you see the point by now. That simply focusing on vendor lock-in is a way too narrow view of the world. There is lock-in everywhere whether you realize it or not. If you haven’t found it yet, you haven’t looked hard enough. Just as there is always tradeoffs in network design. There is lock-in in vendors. There is lock-in in tools. There is lock-in in people. There is lock-in in cloud. I don’t put any value in which form is worst, pick your poison and live with the decision. Don’t put on the blinders though and only consider vendor lock-in.