Container versus VMs

Häufig hört man, dass Container sogar virtuelle Maschinen (Virtual Machines, VMs) obsolet machen. Virtualisierung und Container zu vergleichen, ähnelt jedoch dem sprichwörtlichen Vergleich von Äpfeln und Birnen. VMs stellen (virtualisierte) Hardware bereit. «Das eröffnet Unternehmen ab ‹Oberkante Hardware› alle Freiheiten, zum Beispiel bei der Wahl des Betriebssystems», erklärt Thomas Franz. Er leitet den Technologiebeirat beim IT-Dienstleister Adesso. Container-Umgebungen hingegen arbeiteten auf einem Betriebssystem, das für eine bestimmte Hardware-Architektur konzipiert sei. Diese unterschiedlichen Freiheitsgrade hätten Folgen, positive wie negative. Deswegen, so Franz weiter, könne ein Container nicht automatisch auf jeder Hardware-Architektur oder jedem Betriebssystem betrieben werden. Dieser Nachteil spiele in der Praxis jedoch seltener eine Rolle, «da häufig einheitliche Betriebssysteme und Hardware-Architekturen genutzt werden». Für Projekte im IoT-Umfeld sei dies allerdings schon relevanter. So sei ein Container zum Beispiel für einen Intel-basierten Server nicht ohne Weiteres auf einem Raspberry Pi einsetzbar.

Viele Anwendungen, die früher in virtuellen Maschinen liefen, lassen sich grundsätzlich in einen Container verschieben. Wenn man aber irgendwelche existierenden Applika­tionen ohne eine Anpassung in Containern betreibt, dann fügt das diesen Applikationen erst einmal keine neuen Funk­tionen hinzu. Anders ausgedrückt: «Eine nicht skalierbare Single-Instance-Applikation ist auch nach der Containerisierung keine Cloud-native Scale-out-Applikation.»

Es gibt laut Brundert von VMware diverse Applikationen, die sich für eine einfache Umwandlung in einen Container eignen. Die technische Komplexität müsse aber teilweise sehr individuell betrachtet werden. Als Beispiel nennt er Anwendungen, die etwa über keine integrierten Backup-Mechanismen verfügen und daher von externen Backup-Tools abhängig sind. Weitere Fragen seien, ob eine Applikation überhaupt auf dem Betriebssystem unterstützt werde, das der Container-Runtime zugrunde liegt. Oder wie werden Updates an der Applikation gemacht, nachdem sie containerisiert wurde? All diese und noch etliche andere Themen müssten auf jeden Fall be­rücksichtigt werden, wenn eine Migration erfolgreich sein soll.

IT-Abteilungen sollten also die beiden Technologien – sprich virtuelle Maschinen auf der einen und Container auf der anderen Seite – nicht gegeneinander ausspielen: Es sei kein Oder, sondern ein Und, wie Stephan Michard von Dell betont. «Beide Technologien stellen verschiedene Möglichkeiten der Virtualisierung dar und haben ihre jeweilige Berechtigung und ihre Vorzüge – je nach den Anforderungen, die an eine Applikation gestellt werden.» Für virtuelle Maschinen existierten bewährte Management- und Orches­trierungs-Tools und so lange es keine extremen Anforderungen an eine hohe Skalierbarkeit oder sehr kurze Entwicklungszyklen gebe, liessen sich Applikationen auch gut über virtuelle Maschinen bereitstellen.

Felix Grundmann zufolge, Head of Product Management beim Provider Ionos, gibt es durchaus auch Gründe, vir­tuelle Maschinen gegenüber Containern vorzuziehen. Dies sei der Fall, wenn man beispielsweise einen Custom-Kernel ­betreiben, das Gast-Betriebssystem wählen oder eine ­bestimmte Hardware simulieren wolle. Hinzu komme die bessere Isolierung und Sicherheit von Containern, aber auch die Möglichkeit, Work­loads ohne Ausfallzeit «live» zu migrieren. «Vermutlich lassen sich nahezu alle Anwendungen umbauen, um in Containern zu laufen», ergänzt er. Aber: «Technisch gibt es noch Gründe, dass dies nicht immer sinnvoll sein muss.»