Kubernetes And Cloud Portability — It’s Complicated

I’m so sorry. 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 center or on a public cloud. It’s not really your fault. Vendors have been promising all sorts of magical 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

First, let me suggest that the whole idea of multicloud might be wrongheaded. Now, I could be biased. After all, I do work for a cloud provider (AWS). However, I like to think that my bias against multicloud, magical-application-portability thinking stems from it being a really bad idea. As I wrote long before I joined AWS, “Vendors are cleaning up by selling multicloud snake oil while customers keep getting stuck with lowest common denominator cloud strategies and sky-high expenses.”

Of course I’m not the only one with this view. Corey Quinn of the Duckbill Group, who has made a living by snarkily 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, incognizant 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.

So if multicloud isn’t necessarily the best of ideas, following Quinn, and Kubernetes isn’t going to get us there, even if it were a great idea, following Marko, what kind of Kubernetes-fueled portability is a good idea?

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 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 Paul Nash posits. (Miles Ward concurs, arguing, “Our customers [want to] evaluate every few years, not every week; they just want it easy if the landscape changes.”) Rather, it’s just that this isn’t common (for the reasons identified above), nor is it as important as other aspects of portability.

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.

This view is echoed by Knative co-founder Matt Moore (“the real win is the portability of concepts and tools”). Or, as EJ Campbell nicely summarizes, “It’s nice to have transferable skills.”

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.