Container versus Virtualisierung

Am Anfang war der Server. Dann kam auf dem Mainframe und bei Unix-Maschinen die Virtualisierung als Software- oder Hardware-Partition. Dann kam lange nichts und die Welt des Business-Computings erstarrte in unflexiblen Microsoft-/Intel-Systemen (x86) – endlosen Spaghetti-Landschaften aus Silo-Servern mit jeweils einer Anwendung.

Es wurde Zeit für eine Revolution. Findige Ingenieure erfanden ungefähr in den gleichen Jahren die softwarebasierte Virtualisierung für die x86-Welt – Virtualisierung, das heißt Aufteilung eines Servers in viele einzelne Partikel, mal mit VMware vSphere, mal mit Xen (Citrix), mal mit Microsoft Hyper-V oder mit Red Hat KVM.

EMC erkannte alsbald die Wirksamkeit eines Hypervisors, mit dem sich unkompliziert virtuelle Maschinen (VMs) für diverse produktive Applikationen oder Testzwecke einrichten ließen, kaufte VMware und sorgte für eine schnelle Verbreitung: Man entließ die neue Tochter bald wieder in eine (scheinbare) Unabhängigkeit – offen für alle Hardware- und Software-Hersteller und -Plattformen. Die Konkurrenten konnten nur mühsam folgen oder richteten sich in einer Nische ein.

Allen gemeinsam ist, dass eine VM eine Art Betriebssystem darstellt, das über einen Hypervisor die Kernfunktionen einer dedizierten Hardware simuliert – von CPU bis zu Festplatte und Netzwerk. In einer VM ist Platz für ein Betriebssystem und eine Anwendung. Viele voneinander isolierte VMs teilen sich so die Ressourcen eines Servers und reduzieren deutlich die Hardware-Ausgaben eines Unternehmens einschließlich jener für Energie und Kühlung. VMs lassen sich verschieben, was Alternativen für Replikation und Backup ermöglicht.

Doch mit der Anzahl von VMs in einem Rechenzentrum er­höhen sich auch die Anforderungen an Management und Speicherkapazität. Nicht zufällig spricht VMware von sich selbst heute als von einem „führenden Unternehmen für Cloud-Infrastruktur und Business Mobility“. Denn rund um das ursprüngliche Virtualisierungsszenario gibt es inzwischen ein breites Spektrum an Software-defined-Lösungen für Storage, Networking oder sogar das ganze Rechenzentrum.

Die Größe einer VM beträgt in der Regel mindestens 50 Gigabyte. Der resultierende Overhead führte bei Providern und Großkonzernen wie Google, Netflix oder Twitter dazu, andere Möglichkeiten zu entwickeln. Am bekanntesten sind die Open-Source-Container von Docker. Laut der erst 2013 gegründeten Firma besteht ein Container-Image aus einem „schlanken, eigenständigen, ausführbaren Paket eines Stücks Software, das alles für seine Lauffähigkeit umfasst: Code, Runtime, System-Tools (…).“

Ein eigenes Betriebssystem im Container ist – anders als in einer VM – nicht erforderlich. Verschiedene isolierte Systeme laufen im Host-Betriebssystem und teilen sich seine Ressourcen. Deshalb können viel mehr Container auf der gleichen Infrastruktur laufen, was jedoch wiederum Orchestrierungswerkzeuge wie Kubernetes oder Rocket (CoreOS) erfordert. Gleichzeitig erhöht sich die Anfälligkeit gegen Hacker-Attacken.

Bereits von einem Abgesang von VMs (oder gar von VMware) zu sprechen, wäre dennoch ziemlich übertrieben. VMware hat nämlich reagiert und bietet nun Container an, die in einer eigenen VM laufen. Unternehmen sollten genau überlegen, wann sie sich für VMs entscheiden und wann für Container. Container werden heute gern für DevOps und für Continuous Delivery von Software eingesetzt, während VMs bei großen Applikationen die Nase vorn haben.