Do you really need Kubernetes?

Source:-itworld.com

Is Kubernetes the perfect defense against cloud lock-in, or a needlessly complex solution to a problem nobody has?

Oh, sure, Kubernetes is all the rage and of course you need one. Maybe three! But if you ever stop to think, “Why Kubernetes?”, as Paul Johnston did, well, expect lots (and lots) of opinions.

One of the primary reasons IT professionals cite for embracing Kubernetes is to reduce lock-in by ensuring portability between clouds. This turns out to be better in theory than in practice. And, as Johnston says, the same people who tell him they’re embracing Kubernetes for cloud portability also tell him they have no plans to move.

So, why Kubernetes?

[ Don’t miss InfoWorld’s 2020 Technology of the Year Award winners: The best software development, cloud computing, data analytics, and machine learning products of the year ]
Containerize away lock-in!
Plenty of people find themselves boarding the Kubernetes bandwagon simply because it’s popular. (“Devs and architects want to use it because tech is a fashion industry and Kubernetes is trendy,” says Orion Edwards.) This despite the likelihood, argues James Thomason, that while developers may look at Kubernetes as a way to “run like Google… in reality it’s overkill for all but 0.001% of use cases.”

While this might be overstating the case a bit, Thomason has a point. As an industry we do have a tendency to apply shiny new things well beyond their intended use.

According to Johnston, many CTOs embrace Kubernetes “usually because they have to. Either inherited or because it is what they see as the next big thing (lots of developers for hire) and go for it, then wish they hadn’t.”

Why the regret? Because with Kubernetes comes complexity, complexity that they didn’t have with the vehicle they need most for cloud portability, the lowly Docker container. Or simple shell scripts. Indeed, as Johnston goes on, Kubernetes ends up “way overcomplicating something that has been done for years in multiple different ways.”

Avoiding lock-in is the primary answer people give to Johnston’s “Why Kubernetes?” question. As Dan Selman sees it, “It’s not always a rational fear, but it’s a fear.” Analyst Lawrence Hecht joins in, arguing that “Fear of lock-in is rational. It is rational to want to have an exit strategy even if you don’t plan to use it.”

You want cloud portability to minimize lock-in? You can have it. But you probably don’t need Kubernetes to get there.

[ Also on InfoWorld: 3 ways to kick off a devops program ]
From Johnston’s standpoint, an attempt to evade lock-in should not “automatically mean Kubernetes. We had a decent amount of portability with monoliths sitting on virtual servers. I’d argue we have less portability with Kubernetes now.”

Wait, what? More Kubernetes, less portability? How does that work? According to Neal Gompa, “There are ways to make the applications rely less on those things by leveraging some Kubernetes APIs in clever ways, but in general, you don’t get cloud portability for free with bare Kubernetes.”

Kubernetes behind the scenes
Even if Kubernetes won’t remove lock-in in the real world, it still has value for other reasons. For one thing, as Don Syme highlights, if developers build on Kubernetes they gain valuable skills that transfer between employers, whatever cloud those different employers may be using.

Also, Kubernetes is a great way for enterprises to get a measure of infrastructure abstraction, as Joseph Mente argues, which can help when moving between services even if it doesn’t eliminate lock-in. There is, after all, a reason most enterprises choose a particular cloud, and it’s not for basic compute and storage.

So does Kubernetes matter?

[ DevSecOps: How to bring security into agile development and CI/CD ]
As an industry we have a tendency to fixate on technology even as vendors are in the process of removing the need to fixate on that technology. For example, James Urquhart is almost certainly correct to insist that while, yes, Kubernetes will win, it won’t win by having every developer install and use it. Instead, he suggests, “[Kubernetes] should end up completely hidden under the abstractions that matter.”

In other words, developers may end up using Kubernetes behind the scenes, buried in serverless offerings and the like. But most won’t have to dig into the Kubernetes APIs. And, longer term, Kubernetes will disappear from the lingo of would-be woke Dilbertian managers.