Natürlich brauchen Sie Kubernetes auf jeden Fall - am besten gleich drei davon. Zumindest wenn es nach zahlreichen Verfechtern der Container-Technologie geht.
Foto: Simon_g - shutterstock.com
Wenn Sie sich allerdings einmal tiefergehend mit der Frage nach dem "warum" beschäftigen, erwartet Sie ein ähnlich überbordendes Geflecht an Meinungen, wie den Tech-Experten Paul Johnston auf Twitter:
The number of CTOs that privately tell me that the use of Kubernetes is entirely connected to the ability to "move to another cloud" is huge.
— Paul Johnston (@PaulDJohnston) February 11, 2020
The number of CTOs that tell me "the likelihood of moving to another cloud is nil" is pretty much the same.
So... why Kubernetes?
Einer der maßgeblichen Gründe, warum IT-Profis den Kubernetes-Einsatz forcieren, ist die Vermeidung eines Cloud Lock-in - beziehungsweise, die Portabilität zwischen verschiedenen Cloud-Instanzen zu gewährleisten. Allerdings hört sich das in der Theorie häufig besser an, als es sich in der Praxis gestaltet. Warum also Kubernetes - beziehungsweise: Brauchen Sie es wirklich?
Containerization statt Lock-in?
Nicht wenige Unternehmen springen nur auf den Kubernetes-Zug auf, weil die Container-Technologie gerade ziemlich populär ist. Dabei ist die Wahrscheinlichkeit, dass Kubernetes für die Praxis der meisten Unternehmen Sinn macht, relativ überschaubar, wie James Thomason, CTO bei EDJX meint:
Why Kubernetes? Because Google leveraged its brand equity. People want to be like Google. They think using Kubernetes makes them smarter when in reality it’s overkill for all but 0.001% of use cases. Just wait though. Mass casualties from complexity are coming.
— James Thomason (@ctosays) February 11, 2020
Auch wenn das Statement wohl als etwas übertrieben einzuschätzen ist, ist nicht zu verleugnen, dass die Tech-Industrie durchaus dazu tendiert, Technologien allein deshalb zum Einsatz zu bringen, weil sie gerade angesagt und besonders "fancy" sind. Auch wenn sie in der Praxis dann relativ weit entfernt davon sind, echten Nutzen beziehungsweise Mehrwert zu bringen.
Einige CTOs fühlen sich scheinbar auch einfach dazu verpflichtet, auf Kubernetes zu setzen:
It's 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.
— Paul Johnston (@PaulDJohnston) February 11, 2020
Bereut werden solche Entscheidungen in der Regel, weil Kubernetes - im Vergleich zum "gewöhnlichen" Docker Container oder Shell-Skripten - ein Übermaß an Komplexität im Schlepptau hat. Oder anders ausgedrückt:
HARD AGREE!
— Paul Johnston (@PaulDJohnston) February 11, 2020
This is *exactly* the point. Kubernetes is way overcomplicating something that has been done for years in multiple different ways.
Das Argument des drohenden Cloud Lock-ins greift in vielen Fällen - allerdings stellt sich die Frage, ob das automatisch zum Kubernetes Deployment führen muss:
Definitely agree. 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.
— Neal Gompa (???·???) (@Det_Conan_Kudo) February 11, 2020
Auch wenn Kubernetes in der Praxis keinen Weg aus dem Lock-in darstellen sollte, ergibt der Einsatz der Container-Technologie aus verschiedenen anderen Gründen Sinn. Softwareentwickler etwa können sich durch die Arbeit Skills aneignen, die sich unabhängig von Cloud-Anbietern zum Einsatz bringen lassen. Darüber hinaus können Unternehmen mit Hilfe von Kubernetes ihre Infrastruktur abstrahieren, was wiederum zu mehr Agilität und Flexibilität beiträgt, wenn es darum geht zwischen Services hin und her zu wechseln.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.