Multicloud will Prevent Vendor Lock-in – Fact or Fiction

Today, many organisations are adopting multicloud strategy as their default strategy. The top reasons cited are avoiding vendor lock-in, better negotiations, and taking advantage of the best of breed from different vendors.

The focus of this post will be on one of the most common reasons behind multicloud strategy, avoiding vendor-lock-in.

Vendor Lock-in: Fact or Fiction?

First, let’s start with the definition of multicloud. Oxford definition of multi is “More than one – Many” and this is what multicloud is, using more than one public cloud.

On the surface, the argument seems logical, diversifying your cloud providers will help you avoid becoming dependent on one provider, thus protecting you from vendor lock-in. The issue with vendor lock-in manifests itself in a lack of applications’ portability and reduced capability in dealing with disruptive events affecting a vendor’s cloud services.

Multicloud strategy means becoming vendor-agnostic and adopting standardisation across the different clouds, which sounds great on paper, but in reality, it creates many disadvantages.

If you do a simple “Lift and Shift” of your on-premise workloads to the cloud (migrating to IaaS platform), then you will probably not need to do much customisation. You will need to design for the lowest common dominator of compute, storage, and networking services to maintain portability. How much value will the businesses get out of such basic cloud services?

To get the most value of the cloud, you need to refactor your applications to take advantage of innovative cloud-native capabilities (Automation, Analytics, Intelligence, etc.). This refactoring of your applications, which is known as going deep with a vendor, is in an essence, your vendor lock-in.

The choice organisations face is the choice between an application’s portability vs. innovation with a single cloud deep integration.

Some will propose using a PaaS abstraction layer such as OpenShift or Cloud Foundry running on top of IaaS to maintain application portability between different vendors while moving up the technology stack. I agree, PaaS abstraction layer will offer portability and access to more advanced cloud services, but the abstraction layer itself will become a point of lock-in. Although PaaS abstraction layer offers more access to advanced services than IaaS, you will still not reap the full value of advanced cloud services. In my experience, many developers will use managed containers/kubernetes services for simplicity. They will also take advantage of managed globally distributed databases such as Cosmos DB,  packaged artificial intelligence, and machine learning along with other advanced services to enhance the application.  All these propriety services reduce the portability of an application.

Abstraction layers are not the solution.

So what is the solution?

Have your cake and eat it

The answer to multicloud strategy does not have to be a binary choice between portability and innovation. You can have your cake and eat it by evaluating and categorising your applications based on portability requirements versus innovation needs.

For applications that can benefit from innovation, I suggest embracing lock-in and go All-in with one vendor. There are a few benefits with this approach:

• Maximum Business Value. Full integration with advanced cloud services from one vendor will offer maximum business benefits.
• Better Pricing. By offering more business to one vendor, you get competitive volume discounts.
• Reduce Risks. Standardising solutions built on one cloud platform reduces integration risks and costs by minimising the need to source, secure, integrate, and manage different providers’ services.
• Employees’ Technical Skills. One cloud vendor means you only need to develop one skill set internally, which simplifies the training and recruitment of hard to find technical resources.
• Simpler architecture. Using one cloud vendor removes the need for abstraction layers, thus simplifying the architecture and reducing costs of implementation and operations.

You should consider additional cloud vendors for specific use cases such as Google GCP for its data analytics.

As for applications that require portability, I suggest the following:

• Identify dependencies. Architects need to track any cloud services used that might not be easy to replicate with another cloud vendor.
• Consider decoupling storage from compute in your application architecture to improve flexibility and portability.
• Utilise containers in your application architecture. Containers offer a form of an abstraction layer and as a result, a greater degree of application portability between different cloud vendors.

The concept of vendor lock-in is already a widely accepted practice. Most organisations have adopted VMware vSphere or Microsoft Hyper-V as their server virtualisation platform, which is a strong form of vendor lock-in. Imagine, if avoid vendor lock-in strategy was enforced, organisation will end up with a combination of VMware, Microsoft, Citrix virtualisation platforms, leading to unmanageable operational complexity, increased risk, and higher implementation and management costs. Adopting a multi-vendor in cloud will lead to greater complexities, risks, and costs.

Organisations should consider the benefits of application portability against the benefits of innovation and business value. Having a blanket multicloud strategy might improve application portability, but will increase complexity and sacrifice innovation and business value in the process.

Thank you for Reading.

Nick