A Different Viewpoint of Lock-In


First things first: Go watch this great video on lock-in from Ethan Banks (@ECBanks). We’ll reference it.

Welcome back. Still carrying that pitchfork around screaming about how you want to avoid vendor lock-in? Ready to build the most perfect automation system in history that does multi-cloud, multi-vendor, multi-protocol networking in a seamless manner with full documentation? Nice. How hard was is to build that unicorn farm?

I get it. No one wants to be beholden to a specific vendor. No one likes being forced into buying things. Everyone hates the life of the engineer forced to work on something they don’t like or had to use because someone needed a new boat. Or do they?

Ford and Chevys and Dodge, Oh My!

What kind of car do you drive? Odds are good you’re either ready to get a new one or you’re proud of what you’re driving. I find that the more flashy a car is the more likely people are to talk about how amazing it is. And when there are two dominant manufacturers in a market for cars, you tend to see people dividing into camps to sing the praises of their favorite brands. Ford people love their trucks and won’t hesitate to decorate their bumpers with stickers about the uselessness of a Chevy pickup. Chevy owners will remind you that Ford is an acronym for Found On (the) Road Dead. Ferrari versus Lamborghini. Toyota versus Honda. Tesla versus everyone else. Tell me that car people don’t root for their team.

That’s how it’s always been. However, when you buy a car you are locked in. You have to buy the parts for that car to fix it. Ford starters don’t work in Chevy vehicles. You can’t just pull a motor out of Corvette and drop it into a Mustang. Wanna try to put Lambo tires on your Testarossa? Good luck! You’re locked into a system that has parts for your car. There’s even a specific term for the parts division of Chrysler, which you use when you tell people you drive a MOPAR car.

Why is it that no one cares about lock in when they buy their car? How is it that when making choices between Cisco and Juniper or AWS and Azure that we rail against the need to pick a horse and run with it? How is it that people in IT will go to amazing lengths to over-engineer something to use the most obscure open source routing protocols invented for the sake of making their configs portable only to walk into the parking lot and crawl into a vehicle that has parts that can only be found at the dealer with a 1000% markup on price? How does that compute?

I Take It Back

IT pros see lock-in as a by-product of choices that were made without their input. No one complains about lock-in when they were the ones that got to make the call about which gear to install or which cloud to pick. Lock-in usually becomes a sticking point when the IT contributes were cut out of the decision loop or they didn’t get to voice their opinion for their favorite hobby project on GitHub. The disappointment festers into a feeling that the real problem here is that the evil vendor is just trying to keep us from moving to the solution path that I would have suggested if only they had asked me!

Why do we build networks using standard protocols? Is it so we can rip out huge sections of the network every three years when the incumbent vendor has pissed us off for the last time? Or is it because we want the opportunity to plug in a cheaper device when one fails? Why do we build multi-cloud capable networks? Is it because we hate Bezos or Nadella and we want to stick it to them by moving our workloads whenever we feel like they’ve made a poor strategic decision? Or is it really because some workloads work better in some places and we are trying to keep the rest mobile so we can move them to take advantage of cheaper spot prices like a game of instance whack-a-mole?

Lock-in isn’t a huge problem. It’s the boogeyman we use to cover our real problems: Not feeling heard and valued. We fight back against this by creating more work for ourselves. Instead of paying for the solution with money, we create a solution with an investment of complexity and time spent creating it. You wanna save $10,000 by switching out the gear I suggested for this other model? Fine, I’m going to make it completely open and hard for anyone other than me to use!

Ask yourself honestly: When was the last time you had to completely change your entire setup to a new system or new hardware in less than three months? Pandemic craziness aside, most IT departments can’t even figure out which printers to buy in three months, let alone scrap an entire network or cloud deployment for the competitor. And that’s the technical challenge. Let’s say you’ve used OSPF and open standards and avoided anything proprietary because you’re ready to pull the plug the next time that sales drone comes sniffing for a new motorcycle payment. How is your non-locked-in network going to compete with the power of spiffs? Sure, we could rip this whole $VendorA network out right now and replace it with $VendorB and there’s nothing you can do about it! Until Sales Drone mentions they’ll give you 20% off the next license renewal and throw in four new top-of-the-line switches to “test”. All you hard work sunk because Sales Drone and Executive Team speak the same language: money.

I know this sounds dark and ominous. I realize there are some very valid concerns about vendor lock in, like licensing features behind paywalls that are unreasonable or creating dependence on specific features that can be revoked at any time. But that’s not usually where the lock-in discussions go for IT pros. No, they usually go back to “$VendorA made me mad once and I will never use $ProtocolA again just to spite them!” Lock-in discussions are almost always really about the staff not getting exactly what they want and using their skillsets to create complexity as a panacea for what they perceive as the chance to move away when the executives want to listen to them again. What generally follows is a network that is difficult to maintain and doesn’t hit performance metrics. That means the executives’ decisions are punished. Not through sabotage. Not through malice. But through the decisions by their staff to try and create a system that make things portable when they don’t need to be just in case someone changes their mind sometime in the future.


Tom’s Take

I expect the comments section to light up on this one. Yes, lock-in is a thing. Yes, there are some very specific cases where it’s a Bad Thing (TM). I’m just pointing out that, like the car discussion above, most of the time the average person couldn’t care less about lock-in as long as it was their decision. The same people that will put a sticker of Calvin peeing on a Ford logo on their car chafe at the idea of having to use Cisco’s flavor of OSPF because one area they will never configure isn’t 100% standard. Lock-in is an issue. It’s not the world-ending problem we make it out to be. And it’s certainly not the boogeyman that scares us into making things needlessly complicated to the point of absurdity just to prove a point.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s