In diesem ersten Post, möchte ich Docker grob vorstellen und im nächsten Teil eine Beispielanwendung veröffentlichen.
Docker ist eine interessante technische Entwicklung, welche uns zeigt, dass wir uns aktuell in jeder Ebene in die selbe Richtung bewegen – immer weiter in die Abstraktion von Komplexität.
Bevor ich auf Docker selbst eingehe, möchte ich einige Gedanken zur Grundlegenden Überlegung los werden.
Seit Jahren sieht die Bewegung auf dem technischen Markt gleich aus: Abstraktion.
Damit möchte man Komplexität nehmen, System und Anwendungen weniger Abhängig voneinander machen und damit Verbesserung, Bereitstellung und zukünftige Bewegung der Software vereinfachen.
Beim Schreiben der ersten Anwendungen, stellen viele fest, dass es enorm aufwendig ist wichtige Teile der Anwendung zu verbessern, anzupassen oder gar auszutauschen. Dadurch kommt es zu einem fundamentalen Konflikt ****und man muss sich entscheiden, ob man
- das Projekt aufgibt (traurig 😔)
- die Änderung macht (aufwenig)
- das Projekt so ändert, dass zukünftige Änderungen leichter sind (sehr aufwenig)
Im Grunde möchte gute Software Kopplungen niedrig halten und Kohäsion stärken.
Dieses Konzept, bekannt in der Softwareentwicklung, lässt sich natürlich u. a. auf das Konzept von virtuellen Maschinen (VMs) übertragen. So merkt man, dass die Welt auch hier wieder ganz ähnlich aussieht.
Früher hat man eine VM gehabt, welche für eine bestimmte Software verantwortlich war – beispielsweise hat man eine VM, welche eine Datenbank betreibt. Braucht mehr mehr Datenbanken, muss man eine neue VM erstellen – und das dauert vergleichsweise lange.
Eine VM jedoch hat viele Abhängigkeiten, die für die Datenbank eigentlich nicht von Bedeutung sind – jedes mal muss beispielsweise mit der VM ein Betriebssystem installiert werden. Damit ist die Kopplung ziemlich hoch und die logische Aufgabe der VM ist nicht nur die Datenbank, weshalb sie keine einzige definierte Verantwortung hat (niedrige Kohäsion).
Eine VM ist damit sehr ineffizient und sollte heutzutage nur genutzt werden, wenn man Container nicht nutzen kann.
In Abbildung 1 erkennt man einen ungefähren Aufbau einer VM-Architektur. Die Hardware wurde durch die Virtualisierung weg abstrahiert, weshalb eine VM seinen Kernel (Guest OS), die jeweiligen Abhängigkeiten und natürlich den Code oder die Software benötigt, die man darauf laufen lassen möchte.
Wenn man das Prinzip von DRY auf dieses Bild anwendet, erkennt man, dass der Kernel eine Sache ist, die sich wiederholt, aber eigentlich nicht wirklich etwas mit der Dienstleistung zu tun hat, die man liefern möchte. Man sollte diese also separieren können, um nicht unnötig Resourcen zu verschwenden.
Container kommen zur Rettung
Nun sollte es eindeutig geworden sein, dass eine VM-Architektur ein fundamentales Problem aufweist. Docker bietet dafür die Möglichkeit diesen Teil zu abstrahieren.
Durch die Abstraktion des Kernels/des Betriebssystems, tritt man in eine Welt ein, die schnellere Bereitstellungen, einfache Weitergabe und höhere Skalierbarkeit erlaubt.
Bevor wir zu tief in die Details gehen, können wir es einfach ausprobieren.