How to Prevent Lock-In for DevOps Tooling

We've talked about a lot in this series about DevOps tooling:

1. Start Your DevOps Journey by Looking at the Value You Add
2. Why Choosing a One-Size-Fits-All Solution Won’t Work
3. How to Choose the Right Tools in Your DevOps Toolchain
4. How to Prevent Tool Sprawl in Your DevOps Toolchain

In this installment, we'll talk about how to prevent lock-in for tooling. Lock-in makes a customer dependent on a vendor for products and services, and likewise unable to use another vendor without substantial switching costs. There are different variations of lock-in. In IT, lock-in is usually created by either a vendor or a technology.

Vendor Lock-In

Vendors try to keep you locked to their products and services by creating a complementary, integrated ecosystem of products. By offering a single service at very low cost, or with very low barriers to entry, customers are drawn in. Once using that initial service or product, it's easier to persuade customers to use more services in the portfolio. A notable, recent example is Amazon AWS. They drew in the masses by offering cheap and easy-to-use cloud object storage services. By offering services adjacent to or on top of S3, AWS made it easy for customers to increase their AWS spend. Other examples include proprietary file formats that only work with the vendor's software. While these are positive examples, there are many less appealing strategies for vendors to keep you from leaving their products behind. In many cases, they raise barriers by increasing the cost of switching to another service.

Technology Lock-In

In some cases, leaving behind a piece of technology is nearly impossible. Often caused by technical debt or age, technological lock-in is more than the high cost of switching, it’s the impact on business processes. Great examples include the mainframe systems and the COBOL programming language many banks still use. Switching from these (very old) technologies has a big impact on business processes. The risk of switching is simply too high. In many cases, lack of knowledge or documentation on the old systems are the cause of the lock-in. Admins are afraid to touch, change, or upgrade the systems, and won't fix if it ain't broke. If systems are ignored for long enough, the mountain of debt grows so high that switching is no longer viable.

How Do We Prevent Lock-In?

There's an odd parallel between preventing technological lock-in and the DevOps movement itself. If DevOps is about accelerating the delivery of work, making each change as small as possible, incorporating feedback, and learning from data and information, then preventing a technological lock-in is all about continuously changing a legacy system to keep documentation, skills, and experience with those systems up-to-date. It prevents knowledge from seeping away and ensures IT engineers have hands-on experience. Simply put, it's a matter of not ignoring a system, but instead changing and transforming it continuously. Vendor lock-in, on the other hand, is harder to spot and fight. You should want a certain, manageable, level of lock-in. Vendor lock-in has many advantages: it lowers barriers, cuts costs, and makes it easier to implement. Remember the AWS example? It's easier to spin up a virtual machine in EC2 to process your data, stored in S3, than to move the storage to another cloud provider first. So realistically, there's always lock-in, but it's a matter of how much switching cost an organization is willing to bear.

The Exit-Before-You-Enter Strategy

There's always lock-in, be it technological or vendor-based. The amount of lock-in you're willing to accept depends on the different products you use. To enter a lock-in willingly, you can use the exit-before-you-enter strategy to help you think about what the future switching cost will be, roughly, if you start using a service or product.

The Loosely-Coupled Strategy

By loosely coupling different products or services, there's less lock-in. By using APIs or other standard integrating interfaces between services or applications, switching out one service for another becomes much easier, as long as the interface between them doesn't change significantly. Many DevOps tools for CI/CD, monitoring, and software development offer open APIs that create loosely coupled, but tightly integrated solutions.