Kubernetes and cloud portability – it’s complicated
Container doesn’t offer the magical application portability you might expect, but something better
14 September 2020 | 0
You were told that Kubernetes was your key to the golden age of multicloud nirvana. You believed that Kubernetes would give you portability to move applications seamlessly between clouds, whether running in your data centre or on a public cloud. Vendors have been promising all sorts of things with regard to portability and Kubernetes.
Unfortunately, Gartner just weighed in to put the kibosh on the Kubernetes-for-portability panacea. As analyst Marco Meinardi writes, when asked whether companies should embrace “Kubernetes to make their applications portable… the answer is: no.”
It’s not that Kubernetes can’t be used to make applications portable. It can. But the nature of that portability differs from how it’s commonly conceived. So how should companies think about Kubernetes-driven portability?
Can’t get there from here
Corey Quinn of the Duckbill Group, who has made a living by trashing bad IT practices, believes multicloud is “the worst practice” for a host of reasons. As Quinn has written:
[T]he idea of building workloads that can seamlessly run across any cloud provider or your own data centers with equal ease… is compelling and something I would very much enjoy.
However, it’s about as practical as saying “just write bug-free code” to your developers – or actually trying to find the spherical cow your physics models dictate should exist. It’s a lot harder than it looks.”
Which brings us to Gartner.
There are many, many great reasons to use Kubernetes, Meinardi writes. Portability just doesn’t happen to be one of them:
Inquiries show that [the] likelihood [of moving applications between cloud providers] is actually very low. Once deployed in a provider, applications tend to stay there. This is due to data lakes being hard — and expensive – to port and, therefore, end up acting as centers of gravity.
Why hard? Analyst Kurt Marko provides some clues, saying that “transparent, incognisant workload movement is only possible on vanilla container platforms for the simplest of applications.” He then lists a range of hurdles that get in the way of Kubernetes-based portability, including dependence on native cloud features (managed databases, serverless functions, etc.), the difficulty of federating user identity and security policies across platforms, and more.
Portability is really about people
It’s not that you can’t architect an application in such a way as to make it portable across clouds. You can, as software engineer Peter Benjamin notes, and that portability makes more sense if you think of the timeframes in terms of years rather than days or weeks, as Microsoft’s Paul Nash posits on Twitter.
Perhaps the most important way to think about portability comes from Weaveworks CEO Alexis Richardson:
The point is “skills portability” due to using a standard operating model and tool chain. Large organisations want developers to use standard ways of working because this reduces training costs, and removes obstacles to staff moving from project to project. It also makes it easier and cheaper to apply policy if your “platform” (or platforms) are based on the same core set of cloud native tools.
Importantly, those skills help both employers and employees. Kubernetes may not make it simple to move applications between environments (on-premises or cloud), but it does level-set the skills and concepts that a developer can use in each of these environments. Or, as Rancher Labs CTO and co-founder Darren Shepherd puts it, “The portability is that the same approach can be used regardless of cloud, data center, edge, laptop, stateless, stateful, AI/ML, etc.”
In this way, Kubernetes is incredibly important, offering “people portability” that is good for individuals and corporations. It’s not magical application portability. It’s something much better.
IDG News Service