Lock-In: Let Me Count the Ways

DZone 's Guide to

Lock-In: Let Me Count the Ways

Vendor lock-in can occur in several different ways. Let's count them.

· Open Source Zone ·
Free Resource

Image title

Vendor lock-in can occur a few different ways

We've all heard the term "Vendor Lock-in," but many don't know about the wide variety of ways in which this stealthy lock-in takes place. Rigidity and frustration caused by this lock-in can mean high costs for enterprises and unhappiness for developers. With new technologies like virtualization and cloud computing, vendors are finding more ways to force users to stay on their platform and purchase their offerings.  The following list describes the different kinds of lock-in that have been seen in the IT industry.

1. Single-Source Lock-In

This is the most traditional sense of lock-in where the installation, configuration, and development with proprietary software require significant up-front investments. Some vendors won't allow the integration of certain third-party software, and to move away from the vendor's software would have a high cost. Open source helps to fight this kind of lock-in. You should ask these questions when looking at a vendor's solution:

  • Do the license terms avoid restrictions and allow multiple vendors?
  • Are the same license terms available on associated dependent products or enterprise versions?
  • Do the license terms allow you to resell your solution at some point?

2. Single-Service Provider Lock-In

With the advent of SaaS, PaaS, and IaaS, much of the software installed on your organization's infrastructure is being outsourced to service providers. However, companies can soon become locked-in to one way of using that service. For example, they might limit your infrastructure providers and your ability to migrate.  Here are some things to ask about your service provider:

  • Is the cloud service interchangeably available from multiple providers?
  • Is the cloud service deployable on a public cloud infrastructure?
  • Is the cloud service deployable on an internal private cloud infrastructure?
  • Can the service be deployed across multiple cloud types (i.e. hybrid clouds)?
  • Has the service provider offered firm commitments about openness and support for migration?

3. Data Lock-In

This lock-in is especially bad for enterprises that base much of their value on the data they've accumulated and leveraged. All of that data could be lost if a repository service won't let you migrate certain data formats into or out of their store. Enterprises also need to be able to use data processing and analytics software on their data while it's in the repository, and there can be limitations as far as which tools the provider will let them use. You should ask:

  • Is enterprise data, and metadata, completely exposed?
  • Are the APIs for accessing enterprise data complete and usable?
  • Do the APIs for accessing enterprise data conform to open standards?
  • Does the API support bulk data export?
  • Does the API support bulk data import?
  • Does the API support incremental export for mirroring a backup to a location of your choice?
  • Is exported data available in open standard data formats?
  • Are there automated tools for backup or migration of key enterprise data?

4. Programming Model Lock-In

One of the best ways for a platform to lock you in is to dictate their own development models and tooling so that the investment to use it is high enough that you won't want to migrate away. Any versatility provided by the wide world of open software is erased in this case. These questions are important to ask:

  • Are the programming models based on open standards?
  • Is there a variety of tools — IDEs, analytics, management, etc. — available for the platform?
  • Do multiple vendors provide tools that encompass the platform?
  • Is there a sufficient global talent pool familiar with or capable on the platform?

5. Infrastructure Dependency

Sometimes, a vendor's solution will become tightly embedded between the layers of your software stack, producing a strong dependency on their solutions.  The preferable solution will have loose coupling between its layers in the software stack so that you can easily add or remove solutions.  Here are the questions you should think about:

  • Is the platform independent of the operating system?
  • Can the platform run on virtual machine infrastructures provided by multiple vendors?
  • For platform-as-a-service (PaaS), is the platform free from dependencies upon a particular cloud infrastructure?
  • Are any infrastructure services provided by the platform (e.g. storage, identity, user management) also free from lock-in?  Use this checklist recursively on those services.

New open-source projects like OpenStack and WSO2's Stratos platform are fighting cloud vendor lock-in by providing platforms that let you move across multiple vendors or create your own cloud stack without impeding your custom enhancements.  Learn more about Cloud Implementation and avoiding lock-in at WSO2.

Originally published August 2010

architects, architecture, enterprise-integration, infrastructure, interoperability, open source, reliability

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}