Docker ist ein Virtualisierungs-Tool, mit dem sich Anwendungen und Services in unabhängige Container kapseln lassen. Somit lässt sich eine Software über verschiedene Plattformen und Infrastrukturen ausrollen, ohne sie wiederholt an die unterschiedlichen Voraussetzungen in den verschiedenen Umgebungen anpassen zu müssen. Auch die Deutsche Telekom nutzt die Docker-Technologie beispielsweise bei Ihrer PaaS-Lösung AppAgile.

In den letzten Jahren hat die Popularität von Docker rasant zugenommen. Immer mehr Entwickler setzen sich mit dem Tool auseinander. Kaum ein Tag vergeht, ohne dass in einschlägigen Fachmagazinen über die Technologie sowie deren Anwendungsmöglichkeiten und Anwendungsbeispiele berichtet wird. Der allgemeine Tenor: Docker ist im IT-Mainstream angekommen. Doch welche Konsequenzen bringen Container-Strukturen für die Arbeit im IT-Bereich mit sich? In diesem Artikel lesen Sie:

• warum Container für Microservice-Architekturen ideal sind,
• inwiefern Container von der Infrastruktur entkoppelt sind,
• warum Entwickler keinen Source-Code mehr liefern müssen,
• wie die Verantwortung von Entwicklern mit der Nutzung von Containern ansteigt,
• warum Administratoren beim Einsatz von Containern einen Kontrollverlust erfahren können,
• wie sich die Aufgabenfelder von Administratoren ändern,
• warum Container den DevOps-Ansatz befeuern,
• inwiefern Container und Cloud zusammenpassen,
• warum an Docker kaum noch ein Weg vorbei führt und
• weshalb der Umgang mit Containern für Unternehmen eine Umstellung ist.

Konsequenz 1: Effiziente Umsetzung der Microservice-Architektur

Container eignen sich ideal für Architekturen, die auf Microservices basieren. Niemand sollte auf die Idee kommen, eine große monolithische Architektur in einen einzigen Container zu verpacken. Für Anwendungsentwickler sind Container daher das ideale Mittel, um Anwendungen zu modularisieren und einzelne Services unabhängig voneinander zu deployen. Sie unterstützen ideal die effiziente Umsetzung einer Microservice-Architektur.

Konsequenz 2: Container sind von der Infrastruktur entkoppelt

Jeder Container bringt sämtliche Komponenten für die Lauffähigkeit seiner Services mit. Somit verhält sich der Container auf jeder Umgebung gleich – ganz egal, ob es sich dabei um den lokalen PC des Entwicklers, eine Testumgebung oder eine Produktionsumgebung handelt. Es besteht also keine Abhängigkeit von einer Infrastruktur bestehend aus Servern und Netzwerken.

Konsequenz 3: Entwickler liefern Container statt Source-Code

Die Zeiten, in denen Anwendungsentwickler einen Source-Code abgeliefert haben, könnten bald endgültig vorbei sein. Anstelle des Quelltextes liefern Entwickler zunehmend schlichtweg Container (genauer: Images auf denen die Container basieren) ab, in denen sich die Services befinden.

Konsequenz 4: Container verlagern Verantwortung

Da ein Container auf dem lokalen PC des Entwicklers bereits genauso läuft wie in der späteren Produktionsumgebung, liegt auch die Verantwortung für die Lauffähigkeit des Containers größtenteils beim Entwickler. Somit können auftretende Probleme bei den Abhängigkeiten von Software-Libraries oder Fragen nach der Java-Version schon frühzeitig gelöst werden und nicht erst später in der Produktion.

Konsequenz 5: Container sorgen für teilweisen Kontrollverlust aufseiten der Administratoren

Der Container-Gedanke bringt mit sich, dass die Administratoren der Betriebsumgebung unter Umständen nicht wissen, was genau in jedem einzelnen Container steckt. Dieses Wissen ist aber auch gar nicht vonnöten. Da der jeweilige Container direkt vom Entwickler stammt, ist eine Änderung seitens der Administratoren ohnehin nur schwer möglich. Durch die fehlenden Kenntnisse über die Inhalte können Administratoren nicht länger Vorgaben zu bestimmten Software-Versionen durchsetzen. Container erzeugen somit einen teilweisen Kontrollverlust für Administratoren. Selbstverständlich stehen Admins aber nach wie vor Möglichkeiten zur Verfügung, um auch bei der Nutzung von Containern wichtige Software-Updates einzuspielen. Wer die vollständige Kontrolle behalten und trotzdem auf Container setzen möchte, ist gezwungen entsprechende Container (auf Basis von Dockerfiles) selbst zu bauen.

Konsequenz 6: Administratoren erhalten durch Container andere Aufgaben

Die generelle Aufgabenverteilung verändert sich durch den Einsatz von Containern. So übernehmen Entwickler – idealerweise in enger Abstimmung im Rahmen von sogenannten DevOps-Teams (Entwicklung und IT-Betrieb) – zunehmend auch einige Tätigkeiten, die bislang den Teams aus dem Application Management vorbehalten waren. Administratoren der Produktionsumgebung können in die Parameter innerhalb eines Containers nicht eingreifen. Stattdessen eröffnen sich den Administratoren neue Aufgabenfelder. So stellen sie zum Beispiel die Laufzeitumgebung der Container sicher, setzen eine sinnvolle Verteilung der Container im Cluster um und sind für deren Überwachung zuständig.

Konsequenz 7: Container begünstigen den DevOps-Ansatz

Während Entwickler möglichst schnell viele verschiedene Features umsetzen und die neuesten Technologien ausprobieren wollen, verfolgt der technische Betrieb andere Ziele. Seine Aufgabe ist es, einen stabilen und störungsfreien Betrieb zu gewährleisten. Dabei ist der Druck zu maximaler Effizienz aufgrund von Sparvorgaben enorm. Ein neues Software-Release ist bei diesen maximal effizienten Betriebsabläufen in der Regel störend. Der DevOps-Ansatz entstammt dem Wunsch, diese „Mauer“ zwischen Entwicklung und Betrieb abzutragen. Container reißen die Mauer geradezu nieder und sind ideal für DevOps-Teams geeignet. Bedürfnisse der Betriebsphase müssen bereits in der Entwicklung berücksichtigt werden – andererseits gelangt das neueste Release schnell in die Produktion.

Konsequenz 8: Container und Clouds sind perfekte Partner

Container und Clouds passen ideal zusammen. Ressourcensparender als virtuelle Maschinen erlauben Docker-Container eine höhere Packungsdichte und sorgen damit für geringere Kosten. Lose gekoppelte Microservice-Architekturen, die mit mehreren Containern pro Service die Ausfallsicherheit gewährleisten, passen ebenso dazu wie der bei vielen Cloud-Anbietern bereits etablierte hohe Automatisierungsgrad beim Deployment und die Abrechnung nach Ressourcenbedarf.

Konsequenz 9: „Docker or Die“?

Die bisherigen Konsequenzen gelten für alle Container-Infrastrukturen, Docker ist jedoch zum absoluten Platzhirsch unter den Möglichkeiten der Containervirtualisierung avanciert. Entsprechend groß ist schon jetzt der Druck, Docker zu unterstützen. Entwickler suchen sich eine Cloud-Umgebung, auf der sie ihre Container in Produktion bringen können. Wer an seinem jetzigen Betriebsmodell festhält, könnte schon in wenigen Jahren das Nachsehen haben.

Konsequenz 10: Der Umgang mit Containern ist für Unternehmen eine Umstellung

In jedem größeren Unternehmen sind Mitarbeiter tätig, deren Aufgabe es ist, Regeln und Prozesse zu überwachen. So befinden sich in größeren IT-Organisationen Dutzende „Gatekeeper“, die die Funktionalität gewisser Spezifikationen abhaken, ein Betriebshandbuch sehen möchten und die Einhaltung der Betriebsvorgaben prüfen. All diese Prozesse müssen mit der Nutzung von Containern auf den Prüfstand. Manches davon wird in Zukunft obsolet werden, anderes nur noch in einer abgespeckten Version stattfinden. Wahrscheinlich werden sich als Korrektiv jedoch zukünftig neue „Best Practices“ zum Bau von Containern herausbilden.