Die wichtigsten Unterschiede zwischen VM und Container

Bei Containern ist man an das Betriebssystem und die Architektur des Hosts gebunden, als könnten auf einem Sternenzerstörer ausschließlich Schiffe des Imperiums landen. Auf einer VM kann ein beliebiges, kompatibles Betriebssystem installiert werden.

Oft unterstützt oder simuliert der Hypervisor auch eine andere Hardwarearchitektur als der Host, beispielsweise bei Emulatoren. So kann ein Betriebssystem ausgeführt werden, welches auf der Hardware des Hosts nicht lauffähig ist - als würde man ein goldenes Götzenbild durch ein Säckchen Sand ersetzen.

Die Installation verschiedener Betriebssysteme führt dazu, dass man sich gegebenenfalls über deren Lizenzierung Gedanken machen muss. Viele Softwarehersteller bieten dafür eigene Lizenzsysteme an.

Manche Hersteller wie zum Beispiel Apple verbieten die Virtualisierung ihrer Betriebssysteme auf fremder Hard- oder Software, obwohl es technisch durchaus möglich ist.

Ressourcen vs. Sicherheit

Die Ausführung von Containern benötigt weniger Ressourcen als die Ausführung einer VM. Für Letztere wird ein Teil der Ressourcen des Hosts für die Virtualisierung der Hardware über den Hypervisor verwendet. Somit steht nicht die gesamte Hardware für die VM zur Verfügung. Ein Betriebssystem muss zusätzlich ausgeführt werden, was ebenfalls gewisse Ressourcen bindet.

VMs sind isolierte Systeme. Für Angreifer ist es nicht möglich, aus der VM auszubrechen und über den Host auf die anderen VMs zuzugreifen. Gelingt es Angreifern, aus einem Container auf den Kernel zuzugreifen, sind alle auf dem Host befindlichen Container betroffen.

Allerdings stellt der Hypervisor selbst einen zusätzlichen Angriffspunkt dar. Wie jede Software wird auch diese nicht fehlerfrei sein. Um nicht wie der Todesstern zu enden, sind zusätzliche Schutzmechanismen und Strategien erforderlich. Eine Wartung, um den Hypervisor mit Updates zu versorgen, ist oft mit einer Downtime verbunden und somit nicht einfach umzusetzen.

Wurde auf einer VM ein Dienst fehlerhaft konfiguriert, betrifft das nur die eine VM. Ein fehlerhafter Dienst oder Applikation in einem Container kann Auswirkungen wie das Öffnen der Bundeslade haben. Der gesamte Host und alle darauf befindlichen Dienste können in Mitleidenschaft gezogen werden.

Container sind grundsätzlich so konzipiert, dass Daten im Container nicht dauerhaft gespeichert werden. Sofern nicht anders definiert, sind die Daten nach einem Neustart oder einer neuen Bereitstellung weg. VMs verhalten sich wie Computer. Daten, die in einem Ordner abgelegt wurden, bleiben dort, bis sie gelöscht werden.

Bereitstellung erfolgt automatisiert

Container sind darauf hin optimiert, nicht gesichert zu werden. Tritt ein Problem auf, wird der Container zerstört und neu bereitgestellt. Daten, die für die Ausführung der Applikation benötigt werden, sollten außerhalb des Containers in einer Datenbank oder einem Verzeichnis liegen. Diese Daten können gesichert werden. Die Sicherung eines laufenden Containers ist nicht möglich.

Zusätzlich zur Sicherung der Daten einer VM kann auch die komplette VM gesichert werden. Hier wird von der laufenden VM inkl. Speicherabbild ein Snapshot erstellt und gesichert. Nach einem Restore befindet sich die VM im gleichen Status wie zum Zeitpunkt der Sicherung.

Sowohl bei Containern als auch VM kann die Bereitstellung automatisiert werden. Bei einem neuen Container beschränkt sich dieser Vorgang auf das Herunterladen des Images und Starten des Containers. Eine Automatisierung ist erheblich einfacher als bei einer VM.

Nach dem Erstellen einer neuen VM müssen meist noch ein Betriebssystem, Dienste und Applikationen installiert werden. Auch wenn mit System-Images gearbeitet wird, müssen meist mehrere Gigabyte an Daten kopiert werden. Die Bereitstellung einer neuen VM dauert erheblich länger.

Skalierbarkeit ist wichtig

Durch die schnelle Bereitstellung von Containern kann eine horizontale Skalierung (hinzufügen zusätzlicher Instanzen, scale out) einfach umgesetzt werden - vorausgesetzt, der Dienst unterstützt dies. Abhängig von verschiedenen Kennzahlen (etwa Auslastung des Hosts) und Limits (etwa benötigte Ressourcen des Containers) können weitere Instanzen gestartet oder gestoppt werden - vergleichbar mit einem Geschwader T-65 X-Wing.

Da bei Cloudapplikationen häufig die tatsächlich genutzten Ressourcen verrechnet werden, können die Kosten dadurch so gering wie möglich gehalten werden.

Die Bereitstellung einer VM nimmt mehr Zeit in Anspruch. Deshalb wird meistens eine vertikale Skalierung (zusätzliche Ressourcen, scale up) umgesetzt. Das bedeutet, wenn eine Applikation zu langsam ist, werden zusätzliche Ressourcen wie CPU oder RAM zur Verfügung gestellt. Was einem Upgrade einer Dreadnought auf die Executor-Klasse entspräche.

Viele Hypervisors unterstützen das dynamische Hinzufügen von Ressourcen zur Laufzeit einer VM. Um diese im Betriebssystem nutzen zu können, ist oft ein Neustart erforderlich.

Und was ist besser?