Avoiding vendor lock-in with the help of multicloud

Open source can be part of the solution to optimizing the flexibility the cloud enables

A key draw of the cloud is the prospect of almost unfettered flexibility. However, if customers cannot easily move from a cloud provider without incurring significant costs, legal headaches or technological incompatibilities, that flexibility is severely compromised. 

Using multiple cloud providers would seem to offer a neat solution to the problem, but it’s not that simple. We explore the issue of vendor lock-in for cloud customers, why adopting multicloud will not solve the problem on its own and how open source can help.

How vendor lock-in happens in the cloud

If your technology is available from only one provider, and you cannot continue to use it without paying licensing or maintenance fees to that provider, you are experiencing vendor lock-in. Moving to the cloud should free you from this kind of restriction because, to a large extent, you are free to use it on your own terms. For example, all the major cloud providers offer pay-as-you-go pricing, which means that in theory you can shut down your environment, export your data and virtual machines and walk away whenever you choose. 

In addition, cloud services are generally built to support data migration both into and out of platforms. Vendors have developed services and tools to help you migrate your databases and the applications that use them both to the cloud and between clouds. 

However, switching providers in the cloud is not straightforward. Take data transfer, for example: Migrating data between servers that use the same database engine (homogenous migration) is relatively easy. However, a change as minor as a version number can surface a range of issues that must be addressed before moving to a different engine (heterogeneous migration). This could require an entirely different approach and application.

You also have to consider applications that have been built to leverage the specific strengths of your existing vendor’s offerings. Reconfiguring such an application to run natively on another cloud is complex. And this is the kernel of the problem of cloud vendor lock-in: Every provider does things slightly differently, so moving from one to another will always involve some degree of challenge, not least of which is the knowledge gap your team will have in relation to the new vendor’s technologies and approach.

Why multicloud on its own is not the answer

A multicloud approach reduces your dependence on any single vendor, but it is no silver bullet against vendor lock-in. Moving an existing application or workload from on-premises deployment to a cloud-provider’s infrastructure is relatively straightforward, and a buyer is fairly well protected against vendor lock-in. When you pay a cloud vendor for servers, network and storage, the cost of moving your virtual machines to a different cloud provider essentially amounts to the cost of learning a new API for provisioning. 

This is not the case with services. Public cloud vendors tend to design their services with proprietary management tools that function only within that vendor’s cloud ecosystem. For example, to deploy just one application on Amazon Web Services (AWS) you might use services such as Kinesis, DynamoDB, ElastiCache, Simple Queue Services, TimeStream and Lambda – and these are proprietary services only available from AWS. 

Given the cost of refactoring an application developed for one specific cloud platform for a different one, deploying cloud services with complex combinations of higher-level proprietary services makes it difficult to decouple your choice of technology from your choice of cloud vendor. Theoretically, it is possible to run the same workload in multiple clouds, but that means catering to the lowest common denominator and compromising the potential for innovation public cloud enables. 

Your multicloud strategy is more likely to succeed if you design and build each application in the cloud best suited to it. However, expedience rather than analysis often dictates where a workload is deployed. You need to weigh up the relative strengths of each cloud and how they relate to your specific business use case. Without reliable data to indicate how a workload will perform in a chosen cloud, allocating it to the appropriate cloud depends on luck rather than research. 

How open source can help prevent vendor lock-in

Customers can use a range of open-source cloud computing platforms and tools to reduce their dependence on proprietary platforms. Open source effectively decouples your technology choice from your choice of cloud vendor. Developers can adapt the source code of these platforms and tools to their requirements as they deploy, provision and manage workloads and environments. 

Kubernetes, the container orchestration system for automating software deployment, scaling and management, and the service mesh Istio were open-sourced by Google, which has established a reputation as a key leader and contributor to the open-source community.

For example, many Google Cloud Platform (GCP) tools are built on open-source technology, and GCP adds an operation management layer on top to deliver added value and allow customers to adopt the technology quickly. Google Kubernetes Engine (GKE) and services such as Dataflow, Cloud Composer, Managed Service for Prometheus and Cloud Data Fusion are built so that essentially you can take the same business logic and run it anywhere else by simply implementing the new operation aspect. 

A platform like Google’s Anthos enables hybrid multicloud app modernization, allowing you to orchestrate and run Kubernetes clusters and even VMs (in private preview) on GCP, AWS, Azure, private cloud and bare metal. Even if you don’t use Kubernetes as the foundation for your entire cloud, it is useful for orchestrating some of the workloads running within a public cloud.

To ensure the future viability of open source software, companies should encourage and incentivize open-source contributions from their employees. A recent report from CNCF found that 96% of organizations now use Kubernetes, and the number of other cloud-native open-source projects has exploded in the past year. Open-source software can help facilitate an effective multicloud strategy and prevent companies from being held hostage by a single cloud. 

However, there is a trade-off when you rely on significant amounts of open source services: You are responsible for Day 2 operations. That means that you must take care of monitoring, updating and securing, and all that additional work may not be worth the extra resources and processes you will need. 

You will also have to operate with minimal support mechanisms, mostly without any sort of SLA, so you are on your own if there is any kind of outage in production. And what happens when you want to add features to a key service? Your engineers will have to find time to contribute to the open source community instead of working on enhancing the core functionality of your product. As with a multicloud strategy, relying on open source alone to avoid vendor lock-in is not the answer. 

Where to next

So how do you realize the true power of the cloud free from any restrictions a vendor might impose? Working with a partner who is deeply familiar with all the major cloud providers can help you plan your cloud strategy so that you extract maximum business value from the cloud vendor you choose. 

The team at DoiT not only has in-depth experience helping companies harness multiple clouds to achieve their business goals, they have also built open source tools that streamline your cloud operations, solve complex technical challenges and help you reduce your reliance on proprietary platforms. With the right approach, you can leverage the specific strengths of your existing vendor’s offerings while enjoying all the flexibility the public cloud promises.

Subscribe to updates, news and more.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related blogs