Do not make application portability your primary driver for adopting Kubernetes, say Gartner analysts Marco Meinardi, Richard Watson and Alan Waite, because while the tool theoretically improves portability in practice it also locks you in while potentially denying you access to the best bits of the cloud.
The three advance that theory in a recent “Technical Professional Advice” document that was last week summarised in a blog post.
The Register has accessed the full document and its central idea is that adopting Kubernetes can’t be done without also adopting a vendor of your preferred Kubernetes management tools.
“By using Kubernetes, you simply swap one form of lock-in for another, specifically for one that can lower switching cost should the need arise,” the trio write. “Using Kubernetes to minimize provider lock-in is an attractive idea, but such abstraction layer simply becomes an alternative point of lock-in. Instead of being locked into the underlying infrastructure environment, you are now locked into the abstraction layer.”
If you adopt Kubernetes only to enable application portability, then you are trying to solve one problem, by taking on three new problems you didn’t already have.
And that matters because “Although abstraction layers may be attractive for portability, they do not surface completely identical functionality from the underlying services — they often mask or distort them. In general, the use of abstraction layers on top of public cloud services is hardly justified when organizations prioritize time to value and time to market due to their overhead and service incongruence.”
The trio also worry that shooting for portability can cut users off from the best bits of the cloud.
“Implementing portability with Kubernetes also requires avoiding any dependency that ties the application to the infrastructure provider, such as the use of cloud provider’s native services. Often, these services provide the capabilities that drove us to the cloud in the first place,” they write.
And then there’s the infrastructure used to run Kubernetes, which the three point out will have variable qualities that make easy portability less likely.
“The more specific to a provider a compute instance is, the less likely it is to be portable in any way,” the analysts wrote. “For example, using EKS on [AWS] Fargate is not CNCF-certified and arguably not even standard Kubernetes. The same is true for virtual nodes on Azure as implemented by ACIs.”
The document also points out that adopting Kubernetes will almost certainly mean acquiring third-party storage and networking tools, which means more elements that have to be reproduced to make applications portable and therefore more lock-in.
Some relief is possible by choosing infrastructure stacks designed to run on-prem and the cloud, such as Google Anthos, Azure Stack or AWS Outposts.
But overall the document suggests you have little choice but to “Choose your point of lock-in, mitigate it as you can and accept it.”
And that choice should be informed by what the three rate a “very low” probability that you’ll ever need portability.
“Most applications won’t migrate between cloud providers due to portability challenges, but most applications don’t require such portability. Data gravity plays a strong role in keeping applications close to where data resides. Moving data is often difficult and expensive. For similar reasons, the use case of moving applications frequently to leverage the least expensive infrastructure has not materialized.”
The advice therefore suggests that building for moves introduces a “portability tax”.
“If you adopt Kubernetes only to enable application portability, then you are trying to solve one problem, by taking on three new problems you didn’t already have.”
But if you decide you are going to use Kubernetes regardless of the above and still value portability, the trio recommend another layer of infrastructure.
Kubernetes moves to end ‘permanent beta’ for some APIsREAD MORE
“Further abstraction is one legitimate approach to avoid lock-in to a specific Kubernetes consumption model and vendor. This approach suggests using a Kubernetes manager of managers such as D2iQ Kommander, Giant Swarm, Google Anthos, Platform9, Rancher, VMware Tanzu Mission control or similar.”
But of course once you commit to such a platform, it becomes another thing you can’t do without.
“The intention of this category of products is to federate the provisioning and management of multiple Kubernetes clusters, across a variety of infrastructures and Kubernetes consumption models,” the analysts write. “However, this carries the risk of creating a new point of lock-in (to the federation product) that is even more egregious than a major cloud provider or software vendor.” ®