On the journey to cloud there are many challenges that need to be considered. One that comes up time and time again is vendor lock-in.

So what does this really mean?

Tech Target defines vendor lock-in as “a situation in which a customer using a product or service cannot easily transition to a competitor’s product or service. Vendor lock-in is usually the result of proprietary technologies that are incompatible with those of competitors.”

This article won’t address the contractual side of things. When you sign up to any service it is imperative to understand the terms and conditions, the client and supplier obligations, the service levels, privacy and compliance. Instead this article will focus on some of the misconceptions of vendor lock-in, in terms of the technology, design and the architectural choices we have to make when building applications for the cloud.

#1 – Use cloud services or build your own
When designing highly available applications, the following design aspects should be considered. Significant benefits can be realised through designing services for failure.
• Applications should be de-coupled.
• Applications should be scalable at every tier.

With an ever growing number of services for consumption, cloud providers offer a Service-Oriented Architecture (SOA), where application components provide services to other components via a communications protocol – message queuing, database-as-a-service, in-memory caching to name a few. All of these services are managed, maintained and scaled by the cloud providers. This is a complex operation and would require highly skilled technical resources and extensive infrastructure for any organisation to do this for themselves.

We ‘d recommend that by adopting these services organisations can lower the total cost of ownership (TCO) and focus more on delivering value to the business.

All of the “true” public cloud providers (as opposed to providers of private hosting) offer these services. Using their services should not be seen as vendor lock-in but as an opportunity to build better applications.

#2 – Native or open source deployment and automation tools
Portability is another aspect to consider. Some teams think that the way to avoid vendor lock-in is to use open standard deployment tools like Ansible, Terraform, Puppet and Chef, as opposed to using the native deployment tools available from the cloud providers themselves.

It is a little naive though to think that a scripted deployment using an open standard tool on one cloud provider could then be used to re-deploy it to another cloud provider without a considerable re-work. So, there is an argument that by using the native tools the deployments might be more effective. Although if deploying to multiple cloud providers, the effort and investment might be better spent using an open standard tool rather than using the separate proprietary cloud tools for standardisation and reduced support and staff development costs.

We would recommend evaluating the pros and cons of the tools during the selection process against some predetermined criteria. By understanding the capabilities and/or limitations of each of them, as well as the skillsets within your organisation, you will ultimately be able to select the best tool for the job.
By Daniel Rae, Director of Professional Services, SystemsUp