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.