Article (Lesedauer: 4 Min.)

Do you really need Kubernetes?

The short answer is: Yes.

Richard Harris / Rackspace

Kubernetes ist momentan ein großer Trend in der Welt der IT. Ich habe selbst mit dem System gearbeitet und mich wiederholt gefragt, ob sich die Mühe bei der Installation lohnt.

Die kurze Antwort lautet „Ja“.

Große Unternehmen mit engagierten Systemadministratoren und tollen Mitarbeitern im Bereich DevOps werden Kubernetes als nützliche Erweiterung ihrer Umgebung zu schätzen wissen. Das System senkt die Bereitstellungskosten, beschleunigt das Hochfahren von Workloads und reduziert den Aufwand für Sie. Insgesamt nutzen Sie Ihre Hardware also deutlich effizienter, ohne zusätzliche Ausgaben zu tätigen. Kleinere Unternehmen, in denen sich keiner der Mitarbeiter näher  mit Kubernetes auskennt, die das System jedoch nutzen möchten, können mit einem strategischen Partner kooperieren. Dieser bietet wertvolle Unterstützung bei den ersten Schritten. Kubernetes ist inzwischen in der Struktur der meisten großen Unternehmen zu finden, wo sich die Nutzung des Systems im Alltag etabliert hat. Das beweist, dass wir es nicht mit einem Modewort, sondern mit einem Stück Zukunft der Informatik zu tun haben.

Richard Harris

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?

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.

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? 

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.

Does this mean Kubernetes will have lost? No, it means the opposite. When Kubernetes goes back to being invisible plumbing, it will have won, and in a big way.


This article was written by Matt Asay from InfoWorld and was legally licensed through the NewsCred publisher network. Please direct all licensing questions to


Beteiligen Sie sich am Gespräch: Finden Sie Solve auf Twitter and LinkedIn, oder folgen Sie über RSS.

Über den Verfasser

Virtualization Engineer IVRichard Harris

Richard Harris is a Virtualization Engineer IV on the Technology and Engineering Services team at Rackspace. Richard joined Rackspace in 2004 working on Windows Server 2000 and 2003, and has been working in IT for over 25 years. A VMware vExpert...

Erfahren Sie mehr