The next myth in our Monday Mythbuster Series is the idea that lock-in is a bigger issue in cloud computing than with alternative models like on-premise solutions, hosted solutions, etc. It’s a topic we still see often in the press and even in sales cycles. Interestingly enough, it’s one we hear much less often once we engage with our customers in actual implementation and development projects. Perhaps that’s because they realize “lock-in” (like privacy) is a relative term and a fact of life in IT. In fact, the lines between “lock-in”, standardization, commitment, and partnership are subtle ones.
“Lock-in” – whether to a vendor, a platform, a development environment or language – has been an issue for decades and used by numerous vendors as a reason why customers should or shouldn’t move to a technology. “Don’t use Microsoft technologies or you’ll be locked in!” Yet today there are more than 8 million Microsoft developers (although this is something many are trying to change). “If it’s not built using industry-standards, you’re locked in!” Maybe, but SQL is a standard and you don’t see a lot of companies regularly switching their databases. And there’s the newest one…”If you don’t control your data and apps in house, you’re locked in!” Tell that to the companies paying millions to upgrade or rip out their legacy SAP and Lotus Notes systems (which we lovingly refer to as the asbestos of software).
My point is not that you shouldn’t be concerned with lock-in. It’s to say that lock-in is not any more of an issue with the cloud than it is with traditional software. There are however, some key differences between cloud and traditional software that companies should consider.
With traditional software you have the option to run unsupported, legacy versions of old applications as long as you want at no charge. You can’t do that with SaaS. Yet with SaaS there’s a natural buffer for abuse by the vendor that you don’t get with on-premise. SaaS vendors don’t get all their money up-front, they have to continue earning your business. And if one of the large scale SaaS providers does have a major issue, there’s a tremendous market opportunity for third-parties to come in with migration tools that only need to be written once since SaaS applications have a single application version and supporting infrastructure. Compare this to the exponential problem of trying to write migration tools for multiple versions of on-premise applications and all the flavors of infrastructure they run on, and you’ll see why migration tools for cloud apps will be more commonplace in the future.
The Real Considerations Around Lock-in
While lock-in exists, there are things you can do to balance risk with the benefits of the cloud:
- Choose cloud solutions that have full, open APIs – We’ve said this before, not all cloud vendors are created equal. This is one of the reasons why Appirio has a strategic focus on a relatively small set of leading cloud providers. Platforms from Amazon, Google, salesforce.com and Workday have a broad, open set of APIs that more people in the cloud ecosystem are writing against than other market alternatives. Robust APIs create “checks and balances” because they allow for the potential of a single migration solution to be applied to an entire customer base. This helps ensure the SaaS vendors can’t hold customers hostage (e.g. Oracle and their approach).
- Plan implementations and development around the application needs – The more proprietary APIs, protocols and languages you use, the less portable your code and data will ultimately be. But often the more you leverage these proprietary services when building or deploying an application, the faster and more easily you can move to get to a better solution. Lock-in risk should be weighed against the productivity and time-to-market benefits enabled by these more tailored tools.
- Develop the right kind of code, the right way – The more code you write or customizations you make, the more it costs to maintain and the less portability you have (this holds true in both cloud and on-premise environments). Therefore code should be used to develop and extend a solution that creates unique business value. Is that enhancement you are asking for helping create value or just creating work because its trying to reflect the way you’ve done things in the past? Code is powerful when used the right way because it represents what is unique to your business, but when applied without precision it becomes an anchor. When it is necessary, using things like components and SOA help make it more pluggable and better partitioned – resulting in something that can be moved or migrated more systematically. The cloud should make this process easier.
The Future of Cloud Lock-in
As the market matures, lock-in should become even less of an issue with cloud solutions. For one, more tools will become available to make it easier to move data to or from leading cloud providers. The evolution of standards will help here, as will the growing volume of customers on these leading platforms, making it a significant market opportunity to third-party vendors (and likely, an area of investment for VCs).
As we look into a future – one where cloud solutions will play a dominant role and where the concept of lock-in won’t ever completely disappear – consider one thing: If some degree of lock-in is inevitable, isn’t it better to be locked-in on the most advanced version of the product vs. some obsolete technology that becomes unsupported all too quickly? . Being well served by a great solution and great partners is the best protection against the cost of switching because you won’t need to switch. From that perspective, it’s a lot like marriage. Should one worry more about how to best ensure they can get out of it, or focus on making sure they find the best and most compatible partner for the long run???