Virtuelle Maschinen (VMs) begleiten uns schon seit Jahrzehnten. In der heute üblichsten Form (auf x86-Basis) sind sie ungefähr 20 Jahre alt. Sie abstrahieren von der Hardware und stellen den Anwendungen (fast) alles zur Verfügung, was eine Applikation an Ressourcen braucht. Nun brauchen neueste Anwendungsarchitekturen aber keine ganze Maschine, sondern eine Anordnung von Containern. Sterben damit die VMs?
Wer braucht VMs?
Ohne Virtualisierung mussten sich verschiedene Anwendungen entweder dieselbe Maschine teilen oder dedizierte Hardware nutzen. Verschiedene Anwendungen auf derselben Maschine bedeuten immer einen Koordinationsaufwand zwischen verschiedenen Applikationen bzw. ihren Verantwortlichen und mögliche unerwünschte Wechselwirkungen zwischen den Anwendungen. Deshalb gab es in den 1990er Jahren zunächst einen Trend zu dedizierter Hardware pro Applikation. Möglich wurde dieser Trend durch preisgünstige und kompakte x86-Server. Ich kann mich an eine Umgebung mit ca. 2.000 Servern in einer Firma mit weniger als 2.000 Mitarbeitern erinnern. Abhilfe schaffte die Servervirtualisierung. Damit konnte die Materialschlacht im RZ eingedämmt werden. Eine VM bietet den Vorteil, dass sie für eine Anwendung eine dedizierte Maschine nachbildet, aber mit vielen anderen VMs dieselbe Hardware teilen kann. Möglich wurde dies durch Moore’s Law, also der rasant steigenden Dichte von Transistoren und der damit einhergehenden Prozessorleistung. Von dem Trend profitierte vor allem die Firma VMware.
Neue Anwendungsarchitektur
Anwendungen wurden bis vor wenigen Jahren immer nur als monolithische Blöcke konzipiert. Ein Software Image von mehreren Gigabytes war keine Seltenheit. Auf derselben Maschine wurde alles installiert, was eine Anwendung braucht. Meine Zeit als Programmierer liegt Jahrzehnte zurück, aber bis vor kurzem programmierte man so wie ich damals: Man konnte zwar modular programmieren, aber sämtliche Unterprogramme, Bibliotheken etc. mussten auf derselben Maschine zur Verfügung stehen und eingebunden werden. In den letzten Jahren hat sich daran etwas geändert. Man geht weg von monolithischen Anwendungen zur Microservice-Architektur. Anwendungsmodule – auch fertige, die man nicht selbst programmiert – findet man in einem Service Mesh. Dieser muss nicht auf dieselbe Maschine beschränkt sein. Als Laufzeitumgebung bieten sich kurzlebige Container, die irgendwo im Netz laufen. Diese müssen natürlich orchestriert werden. Dafür gibt es Werkzeuge wie Kubernetes.
Wie viele Abstraktionsschichten?
Wenn neue Anwendungen keine ganzen Maschinen mehr brauchen, sondern nur noch eine Anordnung von Containern, fragt man sich, ob man zusätzlich zu dieser neuen Abstraktionsschicht noch VMs braucht. In der Container-Architektur übernehmen sogenannte Pods typische Funktionen einer VM wie zum Beispiel die Verwaltung von TCP-Ports. Ein Pod ist von außen über eine IP-Adresse erreichbar. Über den Pod sind die darin verwalteten Container zu erreichen. Man kann eine Pod-Architektur ohne eine VM-Abstraktion direkt auf Hardware abbilden.
Container sind nicht alles
Aber Container sind nicht alles. Es gibt noch viele Anwendungen, die ganze Maschinen brauchen. Bis sie neu geschrieben sind, werden Jahre vergehen. Außerdem wird eine mandantenfähige Umgebung weiterhin mit VMs realisiert. Beispiel Cloud: Eine virtuelle Serverinstanz in der Cloud ist eine VM. Gleiches gilt für Mandantentrennung im eigenen RZ.
Der Netzwerk Insider gehört mit seinen Produkt- und Markt-Bewertungen rund um IT-Infrastrukturen zu den führenden deutschen Technologie-Magazinen. Der Bezug des Netzwerk Insiders ist kostenlos.
