Containerisierung oder virtuelle Server?

Die Einführung einer neuen internen Anwendung scheitert in vielen Unternehmen nicht an der Entwicklung. Die Anwendung wird fertiggestellt, aber dann tauchen Fragen auf: Auf welchem Server soll sie laufen, wie wird sie gesichert, wer aktualisiert sie, was passiert im Fehlerfall und wie kann sie später erweitert werden? Die Frage nach der Containerisierung oder virtuellen Servern ist daher nicht nur eine Infrastrukturentscheidung. Sie bestimmt, wie vorhersehbar ein geschäftskritisches System funktioniert und wie viel Aufmerksamkeit es vom IT-Team erfordert.

Eine gute Entscheidung basiert nicht darauf, welche Technologie moderner ist. Zuerst muss verstanden werden, welchen Geschäftsprozess die Anwendung unterstützt, wie groß der Ausfall bei einem Fehler wäre, wie schnell sich das System ändert und ob es einen echten Betriebsverantwortlichen gibt.

Zuerst Risiko bewerten, nicht Server auswählen

Nehmen wir eine häufige Situation. Die Bestellungen eines Webshops gelangen über eine individuelle Integration ins Lagerverwaltungssystem, dann ins Abrechnungssystem und schließlich ins System des Kurierdienstes. Bei einigen hundert Bestellungen pro Tag ist diese Verbindungsanwendung kein nebensächliches technisches Element mehr. Wenn sie ausfällt, weiß das Lager nicht, was vorbereitet werden muss, und der Kundenservice sieht den tatsächlichen Bestellstatus nicht.

In dieser Situation ist es nicht entscheidend, ob das Programm auf einer virtuellen Maschine oder in einem Container läuft. Entscheidend ist, ob es wiederherstellbar ist, überwacht wird, Fehler isoliert sind, der Betrieb dokumentiert ist und wer eingreifen kann, wenn der ursprüngliche Entwickler nicht verfügbar ist.

Für die Entscheidung bieten in der Regel fünf Fragen einen nützlichen Rahmen:

• Handelt es sich um eine einzelne Anwendung oder um mehrere Dienste, die sich gemeinsam ändern?
• Wie oft wird eine neue Version oder ein Patch veröffentlicht?
• Muss die Kapazität kurzfristig erweitert werden?
• Gibt es im Haus ausreichendes Betriebswissen und Verantwortlichkeiten?
• Wie viel kostet eine Stunde Ausfall in der Bestellabwicklung, Produktion oder Kundenbetreuung?

Die Antworten auf diese Fragen sagen oft mehr aus als ein langer technologischer Vergleich.

Was bietet der virtuelle Server?

Ein virtueller Server ist eine auf einem physischen Rechner isolierte Umgebung mit eigenem Betriebssystem. Er kann wie ein herkömmlicher Server behandelt werden: Er hat eigenen Speicherplatz, Netzwerkeinstellungen, Benutzerberechtigungen und Systemaktualisierungen. Für ein Unternehmen ist dies oft ein gut verständliches, bewährtes Betriebsmodell.

Es kann besonders gerechtfertigt sein, wenn eine ältere Geschäftsanwendung nur mit einem bestimmten Betriebssystem, speziellen Komponenten oder nach Herstellervorgaben funktioniert. Dasselbe kann für ein Produktionsunterstützungssystem, eine alte Datenbank oder eine Software gelten, die von einem externen Anbieter unterstützt wird und genaue Installationsanforderungen hat.

Der Vorteil eines virtuellen Servers ist die relativ klare Abgrenzung. Eine Anwendung kann ihren eigenen Rechner haben, der gesichert, überwacht und bei Bedarf wiederhergestellt werden kann. Dies kann bei kleineren oder selten wechselnden Systemen einen einfacheren Betrieb bedeuten.

Diese Einfachheit hat jedoch ihren Preis. Jeder virtuelle Server benötigt ein eigenes Betriebssystem, das aktualisiert, geschützt und überwacht werden muss. Wenn im Laufe der Jahre für jede neue Anforderung ein neuer Server erstellt wird, tritt schnell Serverballung auf: Niemand ist sich ganz sicher, was darauf läuft, ob es noch benötigt wird und welche Geschäftsprozesse eine Aktualisierung betreffen könnte.

Der virtuelle Server ist also keine veraltete Lösung. Er ist geeignet, wenn die Anwendung stabil, gut abgegrenzt ist, Änderungen selten sind und eine Trennung auf Betriebssystemebene erforderlich ist.

Was löst die Containerisierung?

Bei der Containerisierung laufen die Anwendung und die für ihren Betrieb erforderlichen Komponenten in einem geregelten, portablen Paket. Ein Container ist kein vollständiger virtueller Server: Er nutzt in der Regel die Ressourcen des Hostsystems, während er die Anwendung in einer isolierten Umgebung hält.

Aus geschäftlicher Sicht ist der wichtigste Vorteil die Wiederholbarkeit. Wenn die Entwicklungs-, Test- und Produktionsumgebung aus demselben definierten Paket aufgebaut sind, ist die Wahrscheinlichkeit des bekannten Problems „es funktionierte noch in der Testumgebung“ geringer. Die Installation erfolgt nicht nach einer langen, teilweise manuell durchgeführten Beschreibung, sondern auf überprüfbare Weise wiederholbar.

Dies ist besonders nützlich für Systeme, die sich häufig ändern. Beispielsweise bei einer Webshop-Integration, bei der ein neuer Kurierdienst, eine neue Zahlungsmethode oder eine neue Lagerregel eingeführt wird. Wenn die Entwicklungen regelmäßig sind, kann der containerisierte Betrieb einen schnelleren und vorhersehbareren Veröffentlichungsprozess unterstützen.

Container passen auch gut, wenn eine Geschäftsanforderung aus mehreren separaten Diensten besteht. Eine Komponente nimmt Bestellungen entgegen, eine andere synchronisiert den Bestand, eine dritte erstellt Dokumente, eine vierte sendet Benachrichtigungen. Diese benötigen nicht unbedingt separate virtuelle Server, können aber separat versioniert, überwacht und bei Bedarf erweitert werden.

Containerisierung ist jedoch nicht automatisch einfacher. Für den ordnungsgemäßen Betrieb sind geregelte Image-Verwaltung, Berechtigungsverwaltung, Protokollierung, Netzwerkkonfiguration, Geheimnisverwaltung, Backup-Strategie und Überwachung erforderlich. Der koordinierte Betrieb mehrerer Container erfordert bereits eine eigene Betriebskontrolle. Wenn dies fehlt, erhält das Unternehmen nicht weniger, sondern nur eine andere Art von Komplexität.

Ein Container ersetzt nicht die Architektur

Ein häufiger Irrtum ist, dass Container von selbst hohe Verfügbarkeit schaffen. Das tun sie nicht. Eine schlecht verwaltete Datenbank, eine Integration mit einem einzigen Fehlerpunkt oder eine undokumentierte externe Abhängigkeit bleibt auch in einem Container ein Geschäftsrisiko.

Verfügbarkeit ist eine Frage der Planung. Es muss festgelegt werden, was bei Serverfehlern, Netzwerkfehlern, fehlerhaften Veröffentlichungen oder Datenverlust passiert. Ist ein automatischer Neustart erforderlich? Wie schnell muss die Wiederherstellung erfolgen? Sichern wir nur die Daten oder überprüfen wir regelmäßig, dass der Betrieb tatsächlich aus dem Backup wiederhergestellt werden kann?

Containerisierung oder virtuelle Server: Wann ist was sinnvoll?

Bei einer stabilen, alten Anwendung, die nur ein paar Mal im Jahr angepasst wird, ist der virtuelle Server oft eine disziplinierte und verhältnismäßige Entscheidung. Es lohnt sich nicht, eine komplexe Containerplattform aufzubauen, nur weil es technologisch möglich ist.

Bei einer regelmäßig entwickelten Anwendung, die mehrere Integrationen verwaltet oder in mehreren Umgebungen läuft, kann die Containerisierung jedoch erhebliche betriebliche Vorteile bieten. Die Fehlerbehebung kann schneller veröffentlicht werden, es wird nachvollziehbarer, was in der Produktion läuft, und die Wahrscheinlichkeit von Fehlern aufgrund von Umgebungsunterschieden ist geringer.

In vielen Fällen ist die richtige Antwort nicht entweder-oder. Container können auch auf virtuellen Servern laufen. Dies ist eine häufige und gerechtfertigte Übergangs- oder dauerhafte Architektur: Die virtuelle Maschine bietet die infrastrukturelle Trennung, die Container die geregelte Bereitstellung der Anwendungen. So muss nicht mit einem großen technologischen Sprung jedes System umgebaut werden.

Es lohnt sich auch, die Natur der Daten gesondert zu betrachten. Anwendungserver, Integrationsdienste und Verarbeitungsprozesse sind in der Regel leichter containerisierbar. Bei einer großen, geschäftskritischen Datenbank haben jedoch Backup, Leistung, Speicherung und Wiederherstellungsanforderungen Vorrang vor den Installationsmoden.

Die versteckten Kosten der betrieblichen Unsicherheit

Bei Infrastrukturentscheidungen wird oft nur die monatliche Serverkosten verglichen. Doch der größere Posten ist oft die unvorhersehbare Arbeit: wenn nur eine Person einen Fehler beheben kann, wenn keine aktuelle Dokumentation vorhanden ist oder wenn vor einem Update niemand sicher weiß, was ausfallen wird.

Die technische Wahl sollte daher die Transparenz unterstützen. Es sollte bekannt sein, welche Anwendung welchen Geschäftsprozess bedient, wo ihre Daten sind, mit welchen Systemen sie kommuniziert, wer dafür verantwortlich ist und unter welchen Bedingungen Änderungen vorgenommen werden können. Dies ist keine administrative Last, sondern die Grundlage für die Kontinuität des Geschäftsbetriebs.

Eine gute Infrastruktur ist nicht wertvoll, weil sie moderne Etiketten trägt. Sie ist wertvoll, weil ein neuer Bestellspitzenwert, ein Systemupdate oder die Abwesenheit eines Schlüsselmitarbeiters den täglichen Betrieb nicht zum Stillstand bringt. Wenn dieses Betriebsbild vor der Wahl geklärt wird, ist die Technologie kein unsicheres Risiko mehr, sondern ein überprüfbares Werkzeug.