Suche
Interview mit Michael Bruns

Muss es denn immer gleich Docker oder Kubernetes sein?

Dominik Mohilo

In seiner Session auf der DevOpsCon 2017 nimmt Sprecher Michael Bruns Container ganz genau unter die Lupe. In unserem Interview erklärt er beispielsweise, wann man um Container fast nicht herum kommt und wann man lieber die Finger davon lassen sollte.

JAXenter: In deiner Session auf der DevOpsCon stellst du die provokative Frage, ob es denn immer gleich Docker und Kubernetes sein müssen. Welche Vorteile bietet der Einsatz von Containern?

Michael Bruns: Das hängt sehr stark vom Anwendungsfall ab. Oft finde ich die Vorteile eher politischer als technischer Natur. Generell kann man wohl sagen, dass Container dem “Works on my machine”-Symptom entgegenwirken. Sie schaffen einen Standard, den alle Entwickler benutzen können bzw. müssen. Dies ist in heterogenen Umfeldern manchmal ohne derartige Hilfsmittel leider schwierig zu erreichen, weil schlicht nicht hinreichend kommuniziert wird oder weil organisatorische Hürden im Weg stehen. Außerdem können mir Container dabei helfen, vorhandene Hardware effizienter auszunutzen, indem ich schwergewichtige Server, die ohnehin schon im Rechenzentrum stehen, für die parallele, isolierte Ausführung mehrerer Container verwende. Darüber hinaus kann ich mit Containern eine Abstraktion von Cloud-Providern erreichen.

JAXenter: Welche Nachteile sind dir in der Vergangenheit beim Einsatz von Containern begegnet?

Michael Bruns: Vor allem habe ich beobachtet, dass Container und deren Orchestrierung als Wunderwaffe gesehen werden, mit der plötzlich alles viel besser und leichter wird. Anstatt darauf zu achten, welche Probleme die in den Containern laufenden Applikationen eigentlich lösen sollen, wird der Fokus viel zu sehr auf die Infrastruktur gelegt. Im schlimmsten Fall führt dies dann dazu, dass ein riesiger, in die Jahre gekommener Monolith mitsamt einem schwergewichtigen Application Server und einer gut gefüllten Datenbank in einem einzigen Container läuft. Einfach nur, damit man sagen kann “Wir machen jetzt Container!”.

Allerdings gibt es auch das umgekehrte Phänomen, das sich gerade von außen betrachtet oft so anfühlt, als würde man mit einem Vorschlaghammer eine Reißzwecke in die Wand nageln. Eine Handvoll kleiner Services soll betrieben werden, was mit Bordmitteln gängiger Provider wie AWS, Azure oder Google Platform und ein bisschen Automatisierung problemlos möglich wäre. Stattdessen wird allerdings alles in Container gepackt und mit Tools wie Kubernetes eine “Cloud in der Cloud” gebaut. Dies führt bei wenigen zu betreibenden Services jedoch zu völlig unnötiger Komplexität, die bisher noch sehr wenige Leute wirklich beherrschen und die nicht selten zu Diskussionen wie “Diese blöde Infrastruktur wird ja niemals fertig!” führt.

Riesige Kubernetes-Cluster auf sündhaft teurer Hardware machen oft auch Monate später nicht viel mehr, als das Rechenzentrum aufzuwärmen.

Viel zu oft erlebt man es auch heute noch, dass beispielsweise ganz klassische CapEx-Planung gemacht wird, bei der man sich für sämtliche Eventualitäten rüsten will, weil gerade Budget vorhanden ist, und dabei beispielsweise von Nutzerzahlen ausgeht, die in der Realität niemals erreicht werden. Dann werden gleich zum Projektstart riesige Kubernetes-Cluster auf sündhaft teurer Hardware eingerichtet, die oft auch Monate später nicht viel mehr tun als das Rechenzentrum aufzuwärmen. Stattdessen würde ich jedem empfehlen, klein und trivial anzufangen, ganz ohne unnötige Schichten und Komplexitätsstufen, und nicht das Pferd von hinten aufzuzäumen. Wenn dann einmal die ersten Schritte gegangen sind, meine Anwendung die ersten Benutzer hat und ich beobachten kann, welche Last tatsächlich zu erwarten ist und wie die Anwendung sich dabei verhält, kann ich mir immer noch Gedanken darüber machen, ob ich überhaupt Probleme habe und wenn ja, ob mir Docker & Co. tatsächlich bei der Lösung helfen würden.

JAXenter: Bei welchem Projekten ist in deinen Augen der Einsatz von Containern unverzichtbar, für welche kann und sollte man auf Docker und Co verzichten?

Michael Bruns: Wenn ich mir beispielsweise im eigenen Rechenzentrum meine “eigene Cloud” bauen möchte, mit schneller Provisionierung von virtuellen Umgebungen und Isolation von Anwendungen und deren Komponenten, sind Docker, Kubernetes & Co gleich von Projektbeginn an eine sehr gute Wahl. Auch wenn ich meine Anwendungen so bauen möchte, dass sie bei mehreren unterschiedlichen Cloud-Providern lauffähig ist, sind Container eine sehr große Hilfe.

Allerdings möchte ich gleichzeitig infrage stellen, ob eine eigene Cloud wirklich das ist, was ich bauen und vor allem betreiben möchte, und ob eine Multi-Cloud-Strategie mehr ist als nur gut klingendes Buzzword. In den allermeisten Fällen ist es meiner Meinung nach eine gute Idee, ganz ohne Docker & Co. zu starten, wenn ich keine wirklich triftigen Gründe hierfür habe. Gerade die Neigung, sich bezüglich beliebiger Cloud-Provider alle Türen offen zu halten und kein klares Bekenntnis zu einem einzigen Anbieter aussprechen zu wollen, finde ich fragwürdig. Wie man so schön sagt: Am besten ist es, die richtige Entscheidung zu treffen, am zweitbesten ist es, die falsche Entscheidung zu treffen – und am schlimmsten ist es, gar keine Entscheidung zu treffen.

Lesen Sie auch: Grundkurs Docker: Theorie und Praxis

JAXenter: Wagen wir einen Blick in die Zukunft, haben Docker und Co auf lange Sicht denn eine Zukunft oder wird bald alles Serverless?

Michael Bruns: AWS Lambda, Azure Functions und deren Alternativen sind tatsächlich für viele Anwendungsfälle sehr gut geeignet. Meiner Meinung nach schließen sich die Konzepte Serverless und Container allerdings gar nicht gegenseitig aus. Serverless ist letztlich ja eine sehr stark vereinfachte Beschreibung von Containern, die rasend schnell und horizontal mehr oder weniger beliebig skalierend gestartet werden können. Frameworks wie Fission zeigen ja bereits, dass man auch mit Docker und Kubernetes ähnliche Konzepte sozusagen von Hand nachbauen kann. Dementsprechend glaube ich einerseits, dass die Zukunft noch deutlich mehr Richtung Serverless gehen wird, dass dies andererseits allerdings durchaus auch mit Docker und Co. möglich ist.

Richtig spannend wird es diesbezüglich meiner Meinung nach allerdings erst dann, wenn weitere Cloud-Provider ähnliche Lösungen implementieren wie Google mit seiner Cloud Engine, was man als Managed Kubernetes bezeichnen könnte. Wenn eine solche Plattform dann auch noch Frameworks wie Fission anbietet, eröffnen sich ganz neue Möglichkeiten, für die nur noch wenig Handarbeit nötig ist. Momentan ist die Hürde für Serverless Marke Eigenbau noch sehr hoch.

Michael Bruns ist Softwareentwickler und -architekt bei inovex. In fast 15 Jahren hat er mehrere große, verteilte Systeme aufgebaut und dabei einige Best Practices und auch Fallstricke kennengelernt. Er ist großer Fan des Leitsatzes “The right tool for the job” und versucht deshalb, Overengineering und unnötige Komplexität mit allen Mitteln zu vermeiden.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.