Cloud Vendor Lock-in: Myth or Reality?
I’m often asked by clients whether they should restrict their use of the more advanced cloud features, such as certain Platform-as-a-Service (PaaS) capabilities. They share a common concern: the fear of vendor lock-in and lack of portability should they want to change their cloud supplier in the future. So is this a genuine threat or an unsubstantiated barrier to achieving cloud adoption?
In some circumstances, I believe their concerns are well founded. That’s because a degree of vendor lock-in is almost unavoidable, whether it’s due to complex PaaS use, or simply down to different standard compute sizing. But it is a concern that can be turned into an opportunity with a common sense approach and, above all, a well-defined exit strategy.
Having had their fingers burnt by legacy vendor lock-in contracts in the past, CIOs today habitually ask how easy it is to get out of traditional IT outsourcing deals if the situation changes. So why shouldn’t the same apply to a cloud solution? After all, we’re still talking about technology services, whether they’re delivered from the cloud or via traditional means. Put simply, when organizations build their cloud business case, they need to factor in the cost of exit along with the obvious benefits of moving to the cloud, such as agility and flexibility.
This is becoming increasingly important as corporate IT pushes ahead with a cloud-first strategy, gradually shifting the balance from traditional IT to cloud environments. The challenge is always that what is right today won’t, in all probability, be right in two or three years’ time. You only have to look at the public sector IT in the UK, which has transformed considerably in only a few years. What would have been heresy to IT leaders in the business impact level-driven world of just two or three years ago, is now increasingly the norm with the adoption of services on Amazon Web Services and Microsoft Azure, or Google’s analytics cloud platform.
These compelling cloud offerings provide the agility that’s essential in today’s fast-paced digital world, but what about in three years down the line? I would urge thinking twice before being seduced into using a single vendor’s full range of complex services to create a custom build. Why? Let’s say you’re customizing all your front-end CRM with cloud-vendor specific components to drive business agility. Staying ahead of the competition over time in this key customer-facing area may require a switch of vendor for some of the components. This can be costly and time consuming unless the possibility is factored in from the outset.
So when it comes to vendor lock-in, there are some fundamental approaches that can help. One important consideration in “future-proofing” your cloud-based applications is the portability of the data. For example, many applications built today using PaaS, may well be delivered in a Software-as-a-Service (SaaS) model in the not so distant future. Today’s differentiating service can become a commodity service in a matter of months. This means that application portability will be less important than data portability because the application is already created and available. So you need to define a path taking your data from PaaS to SaaS, and try to avoid proprietary formatting of data. Further, documenting business rules must be made easy with a standardized format that can then be exported and coded for a new platform or SaaS configuration.
Spending valuable time coding business rules into an application is an investment that needs to be recoverable in the event of a migration.
At a more granular level, the configuration of an infrastructure-as-a-service- (IaaS) based implementation of any serious complexity also needs to be recoverable. The use of tools such as Terraform, and utilizing Object Relational Mapping (ORM) to create abstraction layers so that the design is portable across vendors, is one way to achieve this. Overall, it all comes down to building in portability from the start.
It’s clear that avoiding the pitfalls of vendor lock-in is all about thinking in terms of how you exit the original deal from day one. That means ensuring your design, data and processes are in a standard format that can be easily applied to your future technology environments. If portability is likely to be required, my advice would be to only use niche cloud vendor-specific services where they absolutely provide definite business benefits and justify the Return on Investment within a two to three years’ timeline.
With careful planning and design, vendor lock-in can be significantly reduced and the risk of unplanned costs in the future reduced. The key is to design portability in from the start and to factor the cost of exit into the initial value case. In time, with the development of technologies that implement abstraction layers, portability at the IaaS layer will become increasingly common if designed in from the outset. But for now, care in implementing as-a-service-based solutions so that they are at least aware of the potential exit and migrations costs will ensure there are no nasty surprises later on.
Practical steps to avoid the pitfalls of vendor lock-in
1. Plan Your Exit
Before you go into a new cloud contract, make sure you have an exit strategy in place because nothing stands still in the world of IT. Only think in terms of a two to three year horizon and include the cost of exit in your cloud value case.
2. Manage Your Data
Ensure your cloud solution is data centric. Is there a service that enables you to extract data economically? And is there a “point of presence” where you can get at it easily? Portability of your data will overtake portability of your applications as a priority as your cloud solution evolves.
3. Define The Business Rules
Visible business rules should be defined and documented in a standardized format. This will ensure that there is no additional need to decipher the code and services to create business rule documents for coding them into the new future platform.
4. Ensure agility but rethink the use of proprietary cloud-vendor specific services
Build your case around business benefit, such as agility. Do not use the proprietary cloud-vendor services simply because they are readily available. Be selective; instead of specific proprietary tools, investigate industry standard tooling and frameworks that could be easily migrated to your future technology platform.
You can read more about Capgemini’s Cloud Advise services on our Cloud Strategy page.