Vendor Lock-in

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we're looking at patterns and any patterns in software development, software architecture. And this episode, we're going to look at vendor lock-in. This one is a nice sort of pairing to come after we talked about reinventing the wheel. Because they really are, in a sense, two extremes that we can go to. If we reinvent the wheel, we're basically not using anything that others have done before us. In your lock-in, we are too far, gone too far in using something provided by somebody else. We are too tightly bound to a vendor or a solution, which may be a library or a framework. Now these things, much as in our prior discussion, may or may not be a large issue because it may be something that you are comfortable with. For example, if you are building something for an Xbox, then you're locked in on that distribution platform, on that platform, and that may be fine. You may say, you know what? That's what we're going to do. We're going to build for this thing. And if it disappears, so does our product. Oh, well. We're special for that. Same thing with certain phones. you are building something for Android or for iPhone and you're locked in because in some cases you're in a niche where that's the only place it makes sense. There are certain tools out there and platforms. Salesforce, for example, which is huge and has a lot of add-ons and options that you can do. But you could get in there and build a solution that is specifically for Salesforce because it covers or addresses some weakness of that platform. And I can go on and on, but that's not what vendor lock-in is. And when it's an anti-pattern, we are putting ourselves in a situation where our solution is bigger than that vendor, but we are now limiting ourselves by tying ourselves, binding ourselves too closely to that vendor. Now there are many ways this can happen. And some are more problematic, I guess, than others. You think up at a development language, you're going to be whatever you're implementing in, you're going to be essentially locked into that. But most likely, hopefully, you're in a situation where that language is not tied to a single vendor. Now there have been some in the past. If you go back, and I think it's now open source, somebody may throw some comments out at some point. But Delphi, which was originally very much a proprietary language for Borland initially, and I don't even know who bought it. They've been bought by a thousand different people since then. Or you can look back at some Visual Basic. It was proprietary towards Windows machines. There are things like that, that the language sort of is, but it should, in most cases, be able to break out and allow you to implement on other platforms or other versions. Even Visual Basic was going to, back in the day, allowed you, if you were on three, I Windows 3.1, then you could use Visual Basic still and build Windows 95 apps or Windows 98 apps or 2000 or whatever it happens to be. Yes, you have to recompile and things like that. That's not really the vendor lock-in we're worried about. It is more an issue of having, for example, libraries and frameworks that are tied to a vendor. And yes, you could use them and you can be very effective with them. But if it goes away, you're in a situation, your architecture is too reliant on it. So if that thing goes away, if that vendor's product goes away, your product goes away. You're not able to continue. You're either not able to upgrade or not able to build on it or not able to connect to new customers. There's a lot of different issues that can rise from such a situation. Actually a really bad situation probably that happened in the last few to several years was Flex. You had this, and actually the Adobe Air platform. You had this language, you had this platform, and people were building a lot of Flash-related applications. And then it just sort of went by the wayside. And now it's basically not supported by a lot of systems. Of course, if you're doing anything, it's going to be a retro system, some older system. So that would be a good example of, and I have run into some applications where they were heavily Flash-based. They used a lot of Flash code to do what they wanted to do. And now they're pretty much dead in the water. They have to rebuild, rewrite, restructure, in some cases, the entire application because that was a core piece of how they delivered information or how they got some of the work done. You may see this in databases as well. You may find yourself tightly tied to, I don't know, pick something, Oracle, that you are writing code. Everything you do expects it to be Oracle, expects it to work the way Oracle does. And maybe they get bought or they disappear as a company or decide that they don't want to do databases anymore. And now you're stuck. Those are the kinds of things you want to look out for. And it doesn't have to be big. It doesn't have to be solution-wide types of issues. There can be smaller things. I have seen situations where people are tied to a specific calendar date selector control. This can be and may seem like a very small and trivial thing. But if you have it on all of your forms, then you can have quite a bit of work to deal with if you have to rewrite, remove that piece, that control on all of those, all your forms. It may be a situation where it's not supported moving forward. There's a lot of that that you'll find if you're dealing in the world of a React or Python or some of these other places where there are tons of controls and third-party helper things that are out there, libraries, components, and the like. It's not uncommon, or at least it happens, where you pick one, you're like, great, this is what I'm going to use. And then they stop supporting it, and it just sort of disappears. You may not even have access to it anymore. Or maybe you do, but then you're sort of stuck because if it breaks in future versions of your environment, then it's broken and you don't have a way to fix it. You don't have a vendor to go back to to say, hey, we need this upgraded. So you need to keep an eye out for such things. And it's not so much that you avoid them at all costs. The anti-pattern part of this is where you are using such things and you are too tightly bound to them. So you don't have a way to upgrade them or replace them or remove them. We've seen this in many patterns where you abstract things. You abstract, for example, your database. You abstract the connections into that. You have a middle tier where you have all your logic and you just do very lightweight connections back to your database. So if you want to switch to another database, you don't have to rewrite all your logic in another platform. You can save it. It's essentially doing the correct work in the correct location. If you start bleeding over into other areas, then you can start getting yourself intertwined bound to solutions and controls and options and things like that that you really don't want to be. And that's the sort of the nasty part of this anti-pattern is that you could actually end up in vendor lock-in, not care, maybe not have any real knowledge of it until something happens with that vendor. And then suddenly you realize, oh, we are stuck. And sometimes this can take a while. It may be great for the first year or two or three, but maybe five or six years down the road, things change, vendors move on, stuff like that. And now you're stuck. Now you're in a situation where you have got to find a way to move off of or rewrite around those, that control, that framework, that library. And again, this is not something that's so uncommon that I haven't seen it more than a few times, particularly with applications that have a longer life, as in they're useful and they continue for years as opposed to maybe something that's in steady development and evolves fairly quickly. It's not really, I was going to say one-offs, but these aren't really, maybe they are. They're sort of one-off type solutions. Sometimes you just run it once or twice and you're done. Sometimes they're these little things that have a life of their own. Maybe it's a screen scraper or a data manipulator or some utility type of thing that just does its job. Does it, it's fine. You basically pointed at the system or whatever it is and then just let it go. Schedule it out and it just runs whenever it runs and you don't have any problem with it until you do. And that's the rub is that you get to a point where it's working fine and suddenly something changes, something's not available, something like that. And you don't have a vendor to go to because now it was running smooth and while it was running smooth, the vendor disappeared into the night. Or the platform moved on. Again, for example, think of Adobe Air. Maybe you had something that was really cool, it worked, it was okay and everything was fine until you were forced to move off of Windows XP or something, Windows 2000 or something like that. Sometimes you get to a point where you have to move off of your original platform and if you're too tightly bound to that, it's time for the rewrite. You've managed to get yourself into vendor lock-in and now you're in trouble. That being said, how do we avoid this, particularly when you're thinking about things like the platform itself could evolve and move on? Now it goes back to some of the patterns that we've looked at. Being able to abstract as much as possible the functionality and the display and the control and those other facets of your application into their own standalone pieces. Model view controller being a nice, simple example of this. In this case, I've got my model, I've got my data and then in the view, I've got separately, I've got these things that allow me to display it. And so somewhere along the way, if my display approach or needs changes, I can completely rewrite at least I can rewrite if I have to the view without touching those other pieces. And when you start looking at like microservices and distributed applications and things like that, that's where you're going to be much safer in avoiding vendor lock-in. Now you could end up deploying all of your microservices on the same platform and then end up locked into that vendor, which is not uncommon, where you may have a maintenance or administration type tool that makes it really easy to work with that technology, let's say microservices. But when that tool vendor disappears, now suddenly you are up the creek without a paddle. So keep an eye out for those things. This is a, this is a good place where like a code review, architecture review, things like that can be, it can be very valuable because we're, we're going to go through, we plot out what we're going to do. We create our architecture, we design things, we talk about it. Here's what we're going to do and stop for a second pause and let's assess what we just did because it may be that we painted ourselves into a corner with one of those, you know, or several of those decisions. And while that's not in itself something that will stop us, it may something be something that should cause us pause. So we don't end up three or four years down the road kicking ourselves or cursing the prior developers that are now gone and disappeared off into the sunset. And now it's time for me to disappear off into the sunset. Time for us to wrap this one up and get ourselves back to work. So as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go, Develop-a-Nor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us be great, if you go out to developernor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.