Virtualisierung, Container und Serverless

Virtualisierung, Container und Serverless: die richtige Abstraktion je Last

Virtuelle Maschine, Container und Serverless sind drei Stufen der Rechen-Abstraktion, die Isolation gegen Dichte, Betriebsaufwand und Kaltstart tauschen. Kein Modell ist universell überlegen; jedes gewinnt für eine bestimmte Art von Last.

Die Frage lautet selten, welche Abstraktion die beste ist, sondern welche zu einer konkreten Arbeitslast passt. Eine virtuelle Maschine schottet eine ganze Gastumgebung ab, ein Container teilt sich den Kernel des Hosts und startet in Sekundenbruchteilen, eine Serverless-Funktion ist konzeptionell pro Aufruf kurzlebig, doch die Plattformen halten warme Ausführungsumgebungen zwischen Aufrufen vor. Jeder Schritt nach oben nimmt Betriebsaufwand weg und legt im Gegenzug etwas an Isolation oder Vorhersagbarkeit ab. Diese Seite ordnet die drei Modelle entlang dieser Tauschgeschäfte ein und zeigt, wo welches Modell passt, statt einen Gewinner zu küren.

Die drei Abstraktionsstufen

Die Modelle bauen aufeinander auf, ersetzen einander aber nicht. Sie unterscheiden sich vor allem darin, wie viel des darunterliegenden Systems sie virtualisieren:

• Virtuelle Maschine (VM). Ein Hypervisor virtualisiert die Hardware und gibt jeder VM ein eigenes Betriebssystem mit eigenem Kernel. Das liefert die stärkste Isolation, kostet aber Sekunden bis Minuten beim Start und mehr Arbeitsspeicher pro Instanz. Die VM bleibt die Standardgrenze für mandantenfremde oder regulatorisch heikle Lasten.
• Container. Ein Container teilt sich den Kernel des Hosts und kapselt nur Anwendung und Abhängigkeiten. Das senkt Startzeit und Speicherbedarf drastisch und erhöht die Dichte, also die Zahl der Instanzen pro Server. Die Isolation ist schwächer als bei einer VM, weil der gemeinsame Kernel eine grössere Angriffsfläche ist. Die Open Container Initiative standardisiert Format und Laufzeit, sodass ein Image anbieterübergreifend läuft. Wie Container im Verbund orchestriert werden, behandelt die Seite zu Kubernetes.
• Serverless und FaaS. Function as a Service treibt die Abstraktion ans Ende: Es gibt keinen sichtbaren Server mehr, der Anbieter startet Recheneinheiten pro Aufruf und skaliert bei Inaktivität auf null. Der Betriebsaufwand sinkt am stärksten, dafür entstehen der Kaltstart und eine engere Bindung an die Plattform des Anbieters.

Die Grenze ist nicht scharf. Moderne Serverless-Plattformen laufen oft selbst auf leichtgewichtigen VMs, etwa auf Firecracker, das die Isolation einer VM mit Startzeiten im Bereich von Millisekunden verbindet und so die Trennlinie zwischen Container und VM bewusst verwischt.

Die vier Tauschgrössen

Jede Wahl zwischen den Modellen lässt sich auf vier Grössen zurückführen, die gegeneinander stehen:

• Isolation. Wie stark ist eine Last von ihren Nachbarn getrennt? VMs trennen auf Hardware- und Kernel-Ebene, Container teilen den Kernel, Serverless verlagert die Isolationsfrage zum Anbieter. Wer fremde oder besonders schützenswerte Daten verarbeitet, gewichtet Isolation hoch.
• Dichte. Wie viele Lasten passen auf einen Server? Container und Funktionen packen deutlich dichter als VMs, weil sie kein vollständiges Gastsystem mitschleppen. Höhere Dichte senkt die Infrastrukturkosten, ein Thema, das FinOps systematisch verfolgt.
• Betriebsaufwand. Wer pflegt Patches, Skalierung und Verfügbarkeit? Bei der VM liegt fast alles beim Betreiber, beim Container teilt sich die Last mit der Orchestrierung, bei Serverless übernimmt der Anbieter den grössten Teil. Weniger sichtbarer Aufwand bedeutet zugleich weniger Kontrolle.
• Kaltstart. Wie lange dauert es, bis eine ruhende Last antwortet? Eine laufende VM oder ein warmer Container antwortet ohne Startverzögerung, abhängig von App- und Netzwerklatenz, eine skalierte Serverless-Funktion muss erst hochgefahren werden. Bei latenzkritischen Pfaden wird der Kaltstart zum Ausschlusskriterium.

Diese vier Grössen lassen sich nicht gleichzeitig maximieren. Ein Gewinn an Dichte oder ein Wegfall von Betriebsaufwand wird in der Regel mit schwächerer Isolation oder einem Kaltstart bezahlt.

Der Entscheidungspfad

Statt mit einer Lieblingstechnologie zu beginnen, führt die Abwägung von der Arbeitslast zum Modell. Die folgende Einordnung macht die Tauschgrössen zu einer wiederholbaren Frage:

flowchart TD
    A["Arbeitslast"] --> B{"Starke Isolation<br/>zwingend?"}
    B -->|"ja, fremde Mandanten<br/>oder heikle Daten"| C["Virtuelle Maschine<br/>oder microVM"]
    B -->|"nein"| D{"Last dauerhaft<br/>oder schubweise?"}
    D -->|"dauerhaft, planbar"| E["Container<br/>orchestriert"]
    D -->|"schubweise, ereignisgetrieben"| F{"Kaltstart<br/>tolerierbar?"}
    F -->|"ja"| G["Serverless / FaaS"]
    F -->|"nein"| E

Der Pfad ist kein Automatismus, sondern eine Reihenfolge der Fragen. Isolation kommt zuerst, weil sie am wenigsten verhandelbar ist; danach entscheidet das Lastprofil zwischen dauerhaftem Betrieb und ereignisgetriebenen Schüben; zuletzt klärt der Kaltstart, ob Serverless passt. Viele reale Systeme landen bei einer Mischung, etwa Container für den Kern und Funktionen für seltene, gut abgegrenzte Aufgaben.

Wo die Wahl kippt

• Serverless für Dauerlast. Eine durchgängig ausgelastete Funktion bleibt meist warm, sodass nicht der wiederholte Kaltstart das Problem ist, sondern die Wirtschaftlichkeit und die Plattformbindung: Ohne den Spar-Effekt der Skalierung auf null wird die Abrechnung pro Aufruf teurer und vorhersehbar bindet sie an den Anbieter. Hier ist der Container meist günstiger und portabler.
• VM aus Gewohnheit. Eine zustandslose Anwendung in eine vollständige VM zu packen verschenkt Dichte und erhöht den Betriebsaufwand, ohne dass die starke Isolation gebraucht würde.
• Container ohne Orchestrierung. Einzelne Container von Hand auf einem Server zu pflegen verschiebt den Aufwand nur, statt ihn zu senken. Ab einer gewissen Zahl an Instanzen verlangt das Modell eine Orchestrierungsschicht.
• Kaltstart unterschätzt. Wer Serverless auf einen latenzkritischen Pfad legt, ohne den Kaltstart zu messen, baut eine unsichtbare Verzögerung ein. Vorgewärmte Kapazität mildert das, kostet aber den Spareffekt.

Der Bezug zur Architektur

Die Wahl der Abstraktion ist keine isolierte Infrastrukturentscheidung, sondern hängt am Schnitt der Anwendung. Eine Microservices-Architektur zerlegt ein System in unabhängig betreibbare Dienste, was Container und Funktionen erst sinnvoll macht; ein Monolith profitiert seltener vom feinen Skalieren. Das übergeordnete Paradigma dazu beschreibt Cloud Native, das Containerisierung, Orchestrierung und elastische Skalierung zusammenführt. Ergänzende Bausteine wie ein API-Gateway und ein Service-Mesh regeln den Verkehr zwischen den Diensten, unabhängig davon, ob diese als Container oder als Funktion laufen.

Je verteilter das System, desto stärker wandert die Komplexität in den Betrieb. Durchgehende Observability wird damit zur Voraussetzung, den Zustand kurzlebiger Container und Funktionen überhaupt nachzuvollziehen. Die organisatorische Antwort darauf bündelt das Platform Engineering, das diese Abstraktionen als selbstbedienbare Plattform für die Entwicklung bereitstellt. Als Leistung bildet das die Kompetenz Platform Engineering (IDP) ab; den laufenden Betrieb samt Kostensteuerung deckt die Dienstleistung Platform und FinOps Management ab.

Portabilität und Datenhoheit über die Laufzeit

Die Abstraktionswahl entscheidet mit, wie portabel ein System bleibt und wie viel Kontrolle über seine Daten im Haus bleibt. Serverless senkt den Betriebsaufwand am stärksten, bindet aber meist an die Plattform eines Hyperscalers, deren Recheneinheiten je nach Anbieter ausserhalb der Schweiz oder der EU liegen können. Container sind dank standardisiertem Format am ehesten portabel und lassen sich auf eigener oder schweizerischer Infrastruktur betreiben, was den Vendor Lock-in verringert. VMs und microVMs wiederum liefern die Isolation, die regulierte Lasten verlangen. Wer Kostenvorteil gegen Hoheit und Portabilität abwägt, trifft dieselbe Entscheidung wie bei der grundsätzlichen Make-or-Buy-Frage, nur auf der Ebene der Laufzeit. Die Kostenseite dieser Wahl prüft die Dienstleistung Cloud und FinOps Check.

Referenzen

• CNCF Cloud Native 2024, Approaching a Decade of Code, Cloud, and Change. Zehnte Jahresumfrage der Cloud Native Computing Foundation zur Verbreitung von Containern, Orchestrierung und Serverless. (01.04.2025). www.cncf.io/reports/cncf-annual-survey-2024/
• AWS Firecracker, sichere und schnelle microVMs für Serverless. Open-Source-Virtualisierung, die VM-Isolation mit Startzeiten im Millisekundenbereich verbindet und Serverless- wie Container-Lasten trägt. (2018). firecracker-microvm.github.io
• NIST SP 800-190, Application Container Security Guide. Leitfaden zu den Sicherheitsrisiken von Containertechnologien und Massnahmen über den gesamten Lebenszyklus. (25.09.2017). csrc.nist.gov/pubs/sp/800/190/final
• Open Container Initiative Runtime, Image und Distribution Specifications. Offene Standards für Containerformat und Laufzeit unter der Linux Foundation, gegründet 2015. (2015). opencontainers.org

---

Verwandte Themen

• Cloud Native, das Paradigma, das diese Abstraktionen zusammenführt.
• Microservices, der Architekturschnitt, der Container und Funktionen sinnvoll macht.
• Kubernetes, die Orchestrierungsschicht für Container im Verbund.
• Observability, die Sicht auf den Zustand kurzlebiger Lasten.
• Platform Engineering, die selbstbedienbare Plattform hinter den Abstraktionen.
• Platform Engineering (IDP), das kommerzielle Leistungs-Pendant.