Kubernetes Portability: Must-Have or Shiny Object Syndrome?
What exactly does it mean when we talk about how Kubernetes is portable? As with other aspects of Kubernetes, there’s a mix of what end-users think they want, what they actually end up using and the buzzwords that are thrown around in the industry but don’t necessarily reflect the actual way most organizations use technology.
“What I see from customers, one thing that is extremely scary for them is getting locked into a specific provider,” explained Idit Levine, CEO of Solo.io. These customers, she said, want to know that they could potentially take their containers and run them in Kubernetes on a different provider. They want to know that there is consistency, that the APIs are the same. But does that mean they will actually move? “I would argue that with all our customers, I’m talking about big, huge organizations, I never see it actually happening,” Levine said.
Interestingly, Solo.io did move its entire operation from AWS to Google Cloud because of financial incentives for startups — but Levine’s point is that a technically sophisticated, small, young startup might move between clouds and actually make use of Kubernetes’ promised portability. But it’s a very different story for most end users.
Lock-in has been the bogeyman of programming for decades. “That was the main selling point for C and C++ — oh, this is a portable language,” explained Erik Peterson, chief technology officer and founder at cloud accounting services provider Cloudzero. “It didn’t entirely live up to that, because it needed to be optimized for certain platforms and certain services are only available on one platform. But you’ll see portability talked about in the early days of C, and later with Java.”
Nonetheless, Peterson said, if you look at the enterprises that standardized on Java, they also standardized on specific server platforms and specific operating systems and other specific technology. They never actually followed a strategy that involved moving Java applications around.
It’s hard not to see the talk about Kubernetes’ portability as an extension of this trend: A technology that can theoretically move between environments yet is almost never used in that way.
Multicloud vs. Hybrid Cloud
If we think of portability as meaning that the application can run seamlessly in any environment, the implication is that the user is trying to follow a multicloud strategy — running in multiple public clouds — or needs to run across both a single public cloud and a data center. Some of the concerns are the same, but the business rationale for each strategy is very different.
“These companies that are talking about moving to the cloud now are not born-in-the-cloud companies, and that’s ok,” explained Corey Quinn, chief cloud economist at the analyst firm Duckbill Group. These companies often have their core applications that generate billions of dollars in revenue running in data centers. “So having something that works in both directions is important.”
Cross-cloud portability, on the other hand, is something that Quinn and Peterson think is nearly always a waste of time and money.
The Data Problem
No matter how portable your compute resources are, data is fundamentally non-portable. “The problem is the data. That’s where the stickiness is, and I don’t think Kubernetes is trying to specifically address this problem,” Levine said. “If you are Netflix and all your data is in AWS, you are most likely locked in there. It doesn’t matter if you are using Kubernetes and it doesn’t matter that Google Cloud could give you the same Kubernetes. In order to take all your data from AWS and move to Google Cloud, you would need trucks. Trucks to physically move your data. And that’s insane.”
For a small startup like Solo.io without a lot of data, this doesn’t present a huge barrier to portability. But for larger companies it makes portability a complete pipe dream until data is equally as portable as compute.
“One of the limitations on cloud growth is actually data migration,” Peterson said. “Why else does Amazon invent semi-trailer trucks filled with hard drives to backup to your data center? They can’t get data into the cloud fast enough.”
This may be a maturity issue, Peterson said. If we think of data as having gravity — not just being difficult to move but pulling everything else towards it — there will come a point when most of the data is in the cloud and the “center” of the data gravity will shift from the data center to the public cloud. If that is the case, the hybrid cloud model could just be a legitimate but temporary stop on the cloud journey.
What if we think about Kubernetes and portability completely differently? When we think of Kubernetes being able to run in different environments, the advantage isn’t necessarily about being about to move workloads between those environments, Levine said. It’s actually about being able to move people between projects that are running in different environments.
With Kubernetes, an engineer using Kubernetes on Google Cloud and an engineer using Kubernetes on AWS have a similar experience. If a company has some applications running in Google Cloud and some in AWS — perhaps for strategic reasons, perhaps because of an acquisition — their team can move relatively smoothly between those applications. The user experience is consistent. This might not even be Kubernetes, but rather with something that is built on top of Kubernetes.
Kubernetes portability might feel like insurance for a lot of enterprises — if, theoretically, a cloud provider jacks up their prices they aren’t totally locked in. But by no means does that mean that moving between environments is fast, easy and financially feasible. In most cases, the fact that Kubernetes is portable is essentially beside the point. It doesn’t provide any value for most users and won’t actually be taken advantage of in most cases.
Sure, Kubernetes is theoretically portable. But because that portability is irrelevant for most use cases, it probably shouldn’t factor into decisions to use Kubernetes or not. Developing additional tools to make Kubernetes even more portable is unlikely to make sense in most cases — unless you’re developing a way to move legacy applications to the cloud as part of your migration strategy.