Tag Archives: Lock-in

A Different Viewpoint of Lock-In

Posted on by
Reply

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.

Locked Up By Lock-In

Posted on by
1

When you start evaluating a solution, you are going to get a laundry list of features and functionality that you are supposed to use as criteria for selection. Some are important, like the ones that give you the feature set you need to get your job done. Others are less important for the majority of use cases. One thing tends to stand out for me though.

Since the dawn of platforms, I believe the first piece of comparison marketing has been “avoids lock-in”. You know you’ve seen it too. For those that may not be completely familiar with the term, “lock-in” describes a platform where all the components need to come from the same manufacturer or group of manufacturers in order to work properly. An example would be if a networking solution required you to purchase routers, switches, access points, and firewalls from a single vendor in order to work properly.

Chain of Fools

Lock in is the greatest asset a platform company has. The more devices they can sell you the more money they can get from you at every turn. That’s what they want. So they’re going to do everything they can to keep you in their ecosystem. That includes things like file formats and architectures that require the use of their technology or of partner technologies to operate correctly.

So, the biggest question here is “What’s wrong with that?” Note that I’m not a proponent of lock-in. Rather, I’m against the false appearance of choices. Sure, offering a platform with the promise of “no lock-in” is a great marketing tool. But how likely are you to actually follow through on that promise?

I touched on this a little bit earlier this year at Aruba Atmosphere 2019 when I talked about the promise of OpenConfig allowing hardware from different vendors to all be programmed in a similar way. The promise is grand that you’ll be able to buy an access point from Extreme and run it on an Aruba Controller while the access layer polices are programmed into Cisco switches. It’s the dream of interoperability!

More realistically, though, you’ll find that most people aren’t that concerned about lock-in. The false choice of being open to new systems generally comes down to one single thing: price. The people that I know that complain the most about vendor lock-in almost always follow it up with a complaint about pricing or licensing costs. For example:

The list could go on for three or four more pages. And the odds are good you’ve looked at one of those solutions already or you’re currently dealing with something along those lines. So, ask yourself how much pain vendor lock-in brings you aside from your checkbook?

The most common complaint, aside from price, is that the vendor solution isn’t “best of breed”. Which has always been code for “this particular piece sucks and I really wish I could use something else”. But there’s every possibility that the solution sucks because it has to integrate tightly with the rest of the platform. It’s easy to innovate when you’re the only game in town and trying to get people to buy things from you. But if you’re a piece of a larger puzzle and you’re trying to have eight other teams tell you what your software needs to do in order to work well with the platform, I think you can see where this is going.

How many times have you actually wished you could pull out a piece and sub in another one? Again, aside from just buying the cheapest thing off the shelf? Have you ever really hoped that you could sub in an Aerohive AP630 802.11ax (Wi-Fi 6) AP into your Cisco wireless network because they were first to market? Have you ever really wanted to rip out Cisco ISE from your integrated platform and try to put Aruba ClearPass in its place? Early adopters and frustrated users are some of the biggest opponents of vendor lock-in.

Those Three Words

I’m about to tell you why lock-in isn’t the demon you think it is. And I can do it in three words:

It. Just. Works.

Granted, that’s a huge stretch and we all know it. It really should be “well built software that meets all my functionality goals should just work”. But in reality, the reason why we all like to scream at lock-in when we’re writing checks for it is because the alternative to paying big bucks for making it “all just work” is for us to invest our time and effort into integrating two solutions together. And ask your nearest VAR or vendor partner how much fun that can be?

I used to spend a LOT of my time trying to get pieces and parts to integrate because schools don’t like to spend a lot of money on platforms. In Oklahoma they’re even allowed to get out of license agreements every year. Know what that means? A ton of legacy software that’s already paid for sitting around waiting to run on brand new hardware they just bought. And oh, by the way, can you make all that work together in this new solution we were sold by the Vendor of the Month Club?

And because they got the best deal or the best package, I had to spend my time and effort putting things together. So, in a way, the customer was trading money from the hardware and software to me for my wetware — the brain power needed to make it all work together. So, in a way, I was doing something even worse. I was creating my own lock-in. Not because I was building an integrated solution with one vendor’s pieces. But because I was building a solution that was custom and difficult to troubleshoot, even with proper documentation.

Tom’s Take

Lock-in isn’t the devil. You’re essentially trading flexibility for ease-of-use. You’re trading the ability to switch out pieces of a solution for the ability to integrate the pieces together without expending much effort. And yes, I realize that some lock-in solutions are harder to integrate than others. I’m looking at you, Cisco ISE. But, that just speaks to how hard it is to create the kind of environment that you get when you are trying to create all kinds of integrations. You’ll find that the idea of freedom of choice is much more appealing than actually having the ability to swap things out at will.