Recently I wrote about the often-thorny problem of enterprise-IT lock-in, or using only one vendor’s product for key functions. I discussed how some new technology trends—such as the DevOps movement and the rise of open source—have mitigated, to some degree, the ill effects of lock-in.
But lock-in can still be pernicious. To help IT professionals combat these situations, I think it’s instructive to spell out the specific types of lock-in organizations are encountering today—some of which are more problematic than others. Here is my attempt to classify the types of lock-in, an analysis that I hope informs discussions about whether a particular lock-in scenario is really high cost and hard to evolve, or not.
I see four types of business lock-in. Unfortunately there’s not a lot you can do about these situations once they are in place:
Legal lock-in occurs when actual laws constrain an IT person or developer’s options based on compliance and jurisdiction. For example, sensitive consumer data may be subject to the laws of the country where certain data originates, and the data may have to be stored in a datacenter in that country, or with a limited choice of public-cloud providers. Over time we are seeing public clouds from AWS, Microsoft Azure and Google appearing in more and more countries to address this issue, and they are also conforming to more compliance standards. However, if there’s “only one game in town”, that vendor has lock-in potential.
Political lock-in occurs when a business partnership or investment deal prevents IT alternatives from being considered. For example, if a vendor makes an investment in a company, it could have contractual or political influence to prevent the company from using competing products.
Financial lock-in occurs when an entire budget has already been spent on a product and there’s no more money available to explore alternatives. Enterprises will often optimize for a higher discount by buying a long-term, “all-you-can-eat” deal with one vendor and banning the purchase of alternatives. When the deal term is up, the cost of switching is often high enough that the vendor can exploit the situation and increase its renewal contract value.
Management lock-in occurs when a vendor has a close enough relationship with individual executives that the vendor can influence purchasing decisions and override other considerations. This ranges from trust that a vendor will fix any issues that come up, to peer pressure (“nobody ever got fired for buying from vendor X”), to deals made on the golf course—all the way to deals involving Panamanian shell companies…
It’s possible to escape these three types of technology lock-in with some time and effort.
Interface lock-in is a type of technology lock-in that occurs when the application programming interface or query language differs between components. There can often be some differences in functionality as well, which increases the work needed to switch between vendors. Migration effort tends to be higher for monolithic applications, as everything is tied together with one programming language into a single dependency tree, and often a single database schema as well.
For micro-services, migration tends to be easier and more incremental, as the architecture supports more localized interface dependencies. This allows developers to mix technologies, and support incompatible versions of dependencies via different micro-services at the same time.
Proximity lock-in occurs when systems make assumptions about how long operations take. It’s common to have an application closely tied to a database, for instance, so that any increase in latency between them causes problems. This makes it harder to migrate to a distributed architecture, or to put part of the application on a public cloud while leaving the rest on premise. There are datacenter vendors located next to public-cloud sites to keep latency low, but re-architecting the application to be more latency-tolerant by using a less chatty protocol can help reduce lock-in.
Deployment architecture lock-in occurs when assumptions are made about the layout of replicas in a distributed system, scale requirements, and special hardware features. This isn’t a code-portability issue per se; it’s how the code is deployed. For example, AWS is organized into regions and availability zones. Regions have between one and five zones, and databases like MySQL which use failover-based recovery need at least two zones to operate.
Applications using the Cassandra datastore require a quorum of two out of three zones for availability, and are usually deployed across three zones. Large applications on public clouds, especially in the eastern US region of AWS, may find that they are operating at a scale that isn’t supported in every region or by other vendors.
Three flavors of “soft” lock-in
It’s relatively easy to build systems that are not affected by what I call soft lock-in.
Implementation lock-in occurs when a standard interface exists, but its implementations aren’t exactly the same. If an application is built and tested against several implementations it makes fewer assumptions, and will be more robust and portable rather than locked into a specific vendor and version.
Web service lock-in occurs when parts of an application are implemented via public Web services. When developers pick best-of-breed, they will often end up interfacing with a unique Web service that is specific to a vendor. The key thing to note is that these are “Web” services; they include globally accessible endpoints and use authentication to control who has access to them. This means the rest of the application can be relocated without changing the Web- service dependencies.
For example, the code for an application could run on Microsoft Azure, while the workflow automation is performed using AWS Simple Workflow, with data stored on AWS DynamoDB and streaming analytics through Google Dataflow. Too make this work well, some care needs to be taken with deployment automation and security-key management. But there’s no need for changes to Web-service based application code as it moves between on-premise datacenters and various public-cloud vendors.
Data lock-in occurs when there is too much data to be moved easily. This is a common problem when migrating applications from on-premise deployments to the public cloud, as many datacenters have “just enough” network bandwidth provisioned, and it’s an expensive resource to have sitting idle. Migrating terabytes to petabytes of data can take too long and overload existing links.
One solution to getting data out of the datacenter is to bypass the network using Amazon Snowball devices that hold 80TB and ship them back and forth; this moves over a petabyte of data in a week. Another is to provision extra bandwidth for a specific transition period. Once data is in a public cloud, it can move around much more easily there, since there is huge shared bandwidth inside each cloud vendor. Moving between cloud vendors is also relatively fast since they have much higher Internet connectivity than a typical datacenter. Most public-cloud vendors operate “roach motel” pricing models through which it’s free to send data to them, but they charge around 1c/Gbyte ($10/terabyte, $10K/petabyte) for outbound transfers.
So, to sum up: If you’re facing actual laws that lock you into a certain IT arrangement, or a boss who’s stuck on a certain vendor and refuses to consider alternatives because of that relationship, you might be stuck. But there are ways to get out of “softer” lock-in scenarios, such as those stemming from too much data or certain technology implementations. So don’t despair! Lock-in is not a certainty—you can break out of it.
Note: This post is based in part on a presentation given at a Silicon Valley OpenStack Summit in 2015:
Web Services and Microservices: The effect on vendor lock-in