Muss jeder Entwickler Container, Docker und Kubernetes verstehen? Hinter dieser Formulierung verbirgt sich die Frage, wie weit muss sich die Softwareentwicklerin in eine Technologie einarbeiten.
Auf dem Weg von der Idee einer Software über die Umsetzung bis dauerhaften Betrieb sind mehrere Stationen zu durchlaufen. Konkret betrachtet die Frage den Übergang der Software von »Works on my machine«, d. h. der Entwickler kann das Programm in seiner Entwicklungsumgebung ausführen, zu einer Bereitstellung innerhalb einer größeren Infrastruktur.
Aus hier nicht näher erläuterten Gründen soll die Bereitstellung mit der größtmöglichen Automatisierung einhergehen. Eine heutzutage gern genutzte Möglichkeit ist die Container-Virtualisierung mit Docker und Kubernetes. Die Entwicklerin verfasst eine Beschreibung, wie etwas sein soll. Die Container-Umgebung setzt die Beschreibung um.
Das Aufbauen der Beschreibung bedeutet:
- Ich muss im Großen und Ganzen schon wissen, wie meine Software für sich allein genommen bereitzustellen ist. Dabei geht es um Konfigurationseinstellungen, Speicherplatz, RAM-Zuweisungen, Prozessornutzung.
- Alle Abhängigkeiten (z. B. Datenbankserver, API-Gateways, Zugriffsadressen, Authentifizierung) müssen in dergleichen Weise beschrieben werden.
- Das Zusammenspiel der beschriebenen Bestandteile muss beschrieben werden: welche Teile dürfen welche anderen Teile in welcher Art benutzen?
- Die Beschreibungen sind meistens als Text-Dateien in einer vorgegebenen Form abgelegt.
Diese Schritte wiederholen sich für jedes Projekt, dadurch können spätere Bereitstellungen vorhandene Beschreibungen als Vorlage nutzen.
Konkret
Die Frage ist nun:
Wie weit muss mein Verständnis dieser Beschreibungsdateien gehen? Wie weit muss ich die Virtualisierungstechnik verstehen?
An dieser Stelle helfen zwei Vergleiche: Datenbanksysteme und Dateisysteme.
Datenbanksysteme
Auf dem Markt gibt es eine große Menge an Datenbanksystemen, als Beispiele seien hier MySQL, PostgreSQL, DB/2 und Oracle Database genannt. Der Betrieb jeder der genannten Datenbanken erfordert Spezialistenwissen.
Die Nutzung der Systeme erfolgt jedoch über eine gemeinsame Sprache: SQL. Das heißt, ein Entwickler, der die Sprache SQL beherrscht, kann mit jeder Datenbank arbeiten und sie nutzen. Diese Entwicklerinnen sind universell und für Projekte bis zu bestimmten Größenanforderungen einsetzbar.
Wachsen die Datenmengen über diese Grenze hinaus, ist wieder Expertenwissen gebraucht. Dann müssen die unterschiedlichen Speicherkonzepte und Unterschiede in der Technologie der Systeme bekannt und verstanden sein. Dafür gibt es Experten für genau ein Datenbanksystem. Diese Expertinnen sollten punktuell eingesetzt werden.
Zurück zum Generalisten: Er/sie lernt mit MySQL das Konzept von relationalen Datenbanksystemen und die Sprache SQL.
Sie/er lernt nicht zuerst die Konfiguration von MySQL zu beherrschen, ausfallsichere Systemverbünde zu konfigurieren oder die Unterschiede zwischen den Tabellenspeicherungsmodellen.
Das Konzept und die Nutzung stehen im Vordergrund.
Dateisysteme
Beim Vergleich mit Dateisystemen sind ähnliche Abgrenzungen möglich: Als Entwicklerin benötige ich ein Verständnis, wie ich eine Datei erreiche, also den Speicherort hinreichend genau beschreibe. Dabei kommen Konzepte wie Laufwerksbuchstaben, Verzeichnisse und Dateinamen zum Tragen. Und ich muss die festgelegten Befehle zum Lesen und Schreiben in meiner Programmiersprache kennen. Dann kann ich universell den Großteil der anfallenden Arbeiten bezüglich Dateien abbilden.
Ein Verständnis des Typs des Dateisystems (NTFS, FAT32, XFS, ZFS, usw.) ist meist vernachlässigbar. Auch die interne Abbildung von Dateien in den Kontrollstrukturen des Dateisystems und die Zuordnung von physischen Adressen auf Dateien sind in der Regel für die meisten Anwendungsfälle unbedeutend. Grenzfälle sind auch hier zu finden: Sonderzeichen in Dateinamen, besonders große Dateien oder besonders viele Dateien.
Das Verständnis des Konzepts Dateien ist in vielen Fällen für die Nutzung ausreichen.
Container
Meiner Meinung nach lassen sich die zwei vorgenannten Bereiche übertragen auf die Frage zu Docker und Kubernetes:
Container-Virtualisierung kann ich mit dem Werkzeug/Produkt Docker erlernen. Alle Feinheiten von Docker zu verstehen sind für eine Nutzung (insbesondere die Erleichterung im Entwicklungsprozess) nicht notwendig.
Das Zusammenspiel mehrerer Container kann ich mit dem Werkzeug/Produkt Kubernetes als einem Vertreter der Container-Orchestrierung erlernen.
An dieser Stelle möchte ich den viel belächelten Begriff des Serverless-Computings anbringen. Dieser Blickwinkel auf die Betriebsmittel versetzt mich in die Lage, durch eine Beschreibung meiner Anwendung eine Ausführungsumgebung zu erhalten, ohne die konkrete physische Ausgestaltung kennen zu müssen. Um es auf einen Punkt zu bringen: ich benenne nur die Menge an Arbeitsspeicher und Prozessorleistung, um die Bereitstellung kümmern sich (hoffentlich automatisierte) Prozesse außerhalb der Entwicklungsdomäne.
Fazit:
Ein Entwickler muss nicht Docker oder Kubernetes können. Sie/er muss nicht Docker oder Kubernetes beherrschen. Die Konzepte von geteilten Betriebsmitteln müssen verstanden sein.
Gründe für Schmerzen
Hinter der oben gestellten Frage verbirgt sich noch eine Facette, die meiner Meinung nach viel gewichtiger in der Betrachtung sein muss.
Wie schon in der Einleitung geschrieben, rückt zu einem Zeitpunkt die Bereitstellung und der Betrieb einer Anwendung in den Mittelpunkt. Die hier besprochenen Technologien fordern für ihr Versprechen, Abläufe zu beschleunigen und zu automatisieren, aber eine explizite Beschreibung der Betriebsumgebung ein.
Und nur, wenn ich selbst einem anderen etwas beschreiben kann, habe ich es auch verstanden.
Der Schmerz entsteht nicht bei der Frage, WIE soll ich es beschreiben, wie schreibe ich eine konkrete Anweisungsdatei? Sondern: WAS muss ich alles beschreiben und berücksichtigen, damit ich beim Aufruf einer bestimmten Adresse einen Teil der Anwendung erreiche?
Die Antworten auf diese Frage muss ich unabhängig von der Bereitstellung als Container, als Setup.exe, als virtuelle Maschine oder als physisches Produkt mit Microcontroller-Programmierung erbringen.
Dabei wird dann auch schnell sichtbar, welche Informationen fehlen oder wo das Verständnis des Zusammenspiels mehrerer Komponenten unklar ist. An diesen Stellen sollte nun Wissen und Kompetenz aufgebaut werden.
tl;dr
Entwickler müssen widerspruchsfrei beschreiben können, wie ihre Anwendung ausgeführt wird, unabhängig von der Technologie.