Kubernetes and cloud portability — it’s complicated


I’m so sorry. You were told that 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, 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. 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. , 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.

, 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.

, and that portability makes more sense if you think of the timeframes in terms of years rather than days or weeks, as . (Miles Ward concurs, , “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 :

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 by Knative co-founder Matt Moore (“the real win is the portability of concepts and tools”). Or, as , “It’s nice to have transferable skills.”

, “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.

Copyright © 2020 IDG Communications, Inc.