Wie Red Hat OpenShift Virtualization die DevOps-Transformation auch für traditionelle VM-Workloads ermöglicht
DevOps-Praktiken wie Continuous Integration, Continuous Deployment und GitOps sind bei Container-Anwendungen längst Standard. Doch was ist mit den virtuellen Maschinen, die in den meisten Unternehmen nach wie vor geschäftskritische Anwendungen betreiben?
Traditionell existiert eine Mauer zwischen agilen DevOps-Teams für Container und Operations-Teams für VMs mit klassischen ITIL-Prozessen. Red Hat OpenShift Virtualization durchbricht diese Trennung und ermöglicht moderne DevOps-Praktiken auch für virtuelle Maschinen – ohne die VMs selbst ändern zu müssen.
Die DevOps-Herausforderung in VM-Umgebungen
Historisch gewachsen arbeiten Container- und VM-Teams in getrennten Welten: Entwickler nutzen Git, CI/CD-Pipelines und deployen kontinuierlich, während VM-Infrastruktur oft über separate Tools und Prozesse mit längeren Release-Zyklen verwaltet wird. Diese Trennung führt zu unterschiedlichen Geschwindigkeiten – Container-Services werden mehrfach täglich aktualisiert, VM-basierte Systeme in längeren Intervallen. Das bremst die Gesamtentwicklung, wenn neue Services mit VM-basierten Backend-Systemen interagieren müssen.
Die Konsequenz: Unternehmen können DevOps-Vorteile nicht voll ausschöpfen, solange ein großer Teil ihrer Infrastruktur in getrennten Welten verbleibt.
OpenShift Virtualization: Eine DevOps-Plattform für beide Welten
Red Hat OpenShift Virtualization löst dieses Problem durch einen Paradigmenwechsel: Virtuelle Maschinen werden zu nativen Kubernetes-Objekten. VMs nutzen dieselbe API-gesteuerte, deklarative Verwaltung wie Container.
Die Kubernetes-API als einheitliche Schnittstelle ermöglicht es, VMs mit denselben DevOps-Tools zu verwalten wie Container. Ein Entwickler kann eine VM-Definition in Git committen, CI/CD-Systeme können automatisch Test-VMs provisionieren, und GitOps-Workflows synchronisieren VM-Konfigurationen kontinuierlich.
Dies schafft eine einheitliche DevOps-Umgebung ohne Paradigmenwechsel. Teams müssen nicht mehr zwischen verschiedenen Welten wechseln, und VM-Administratoren profitieren von modernen Automatisierungsmöglichkeiten.
Infrastructure as Code und GitOps für VMs
VM-Definitionen in OpenShift sind maschinenlesbare Manifeste, die alle Eigenschaften beschreiben: CPU, Memory, Netzwerk, Storage. Diese werden wie jeder andere Code in Git-Repositories gespeichert. Änderungen durchlaufen Code-Reviews, werden versioniert und können zurückgerollt werden.
Der Vorteil: Infrastruktur-Änderungen werden nachvollziehbar und reproduzierbar. Ein Developer erstellt eine komplette VM-Testumgebung mit einem Befehl – immer identisch. Infrastruktur-Drift gehört der Vergangenheit an. Aus Compliance-Sicht ist jede Änderung in Git nachvollziehbar.
GitOps mit Git als einziger Quelle der Wahrheit ist der nächste Schritt. Der OpenShift GitOps Operator überwacht Git-Repositories und wendet Änderungen automatisch an. Eine Änderung an einer VM-Definition in Git führt automatisch zur Anpassung der VM-Konfiguration – ohne manuelle Intervention.
Dies bedeutet: Alle Änderungen werden dokumentiert, reviewt und sind auditierbar. Unbeabsichtigte Änderungen werden automatisch korrigiert. Die gleiche VM-Konfiguration kann automatisch auf mehrere Cluster deployed werden – etwa für Disaster Recovery oder geografisch verteilte Installationen.
CI/CD-Pipelines: Automatisierte VM-Deployments
OpenShift Pipelines bietet vollständig integrierte CI/CD für Container und VMs. Ein typischer Workflow:
Entwickler committen Code-Änderungen → Pipeline wird getriggert → baut neues VM-Image → startet automatisch Test-VM → führt automatisierte Tests aus → promotet bei Erfolg in höhere Umgebungen.
Diese Automatisierung reduziert manuelle Fehler dramatisch. Deployments werden wiederholbar und zuverlässig. Die Zeit zwischen Code-Änderung und Produktion verkürzt sich deutlich – auch für VM-basierte Anwendungen.
Besonders interessant bei hybriden Anwendungen: Eine einzige Pipeline orchestriert beide Deployment-Arten, führt End-to-End-Tests über Container und VMs hinweg durch und sorgt für koordinierte Deployments.
Self-Service und automatisierte Testing-Umgebungen
OpenShift Virtualization ermöglicht kontrollierten Self-Service. Entwickler erstellen eigenständig VMs über die Web Console oder API – innerhalb von Administratoren-definierten Grenzen und Quotas. Resource Quotas limitieren Anzahl und Größe, RBAC-Policies definieren granular die Berechtigungen.
Dieser Ansatz löst das Dilemma zwischen Agilität und Kontrolle. Entwickler erhalten Freiheit, schnell zu agieren, während IT-Governance gewährleistet bleibt. Routineaufgaben werden delegiert, sodass sich Operations auf strategische Aufgaben konzentrieren kann.
Automatisierte Testing-Umgebungen werden praktikabel: Für jeden Feature-Branch wird automatisch eine dedizierte Test-VM erstellt. Tests laufen isoliert, nach Abschluss werden VMs automatisch gelöscht. Integration-Tests, die bisher oft übersprungen wurden, werden Standard. Upgrade-Prozeduren können kontinuierlich auf aktuellen Produktions-Snapshots validiert werden.
Praxisbeispiel: DevOps-Evolution eines Logistikunternehmens
Unser fiktives mittelständisches Logistikunternehmen betreibt nach erfolgreicher Migration seine kritischen ERP-, WMS- und TMS-Systeme als VMs auf OpenShift. Parallel laufen moderne Container-Anwendungen wie die mobile Tracking-App.
Die Herausforderung: VM-basierte Legacy-Systeme werden noch nach traditionellen Prozessen verwaltet mit langwierigen Change-Management-Prozessen. Container-Services werden mehrfach wöchentlich aktualisiert. Diese Diskrepanz führt zu Frustration.
Phase 5 – DevOps-Integration:
- Infrastructure as Code: Alle VM-Definitionen wandern nach Git. Das ERP-System wird als deklaratives Manifest beschrieben, identische Staging-Umgebungen entstehen auf Knopfdruck.
- CI/CD für Legacy: OpenShift Pipelines automatisieren Deployments für das WMS-System. Die Zeit vom Commit bis zum Staging-Deployment sinkt von zwei Wochen auf wenige Stunden.
- GitOps-Workflow: Der OpenShift GitOps Operator überwacht Git-Repositories. Änderungen werden automatisch angewendet, manuelle Konsolen-Eingriffe entfallen.
- Self-Service: Entwickler erstellen eigenständig Test-VMs für das TMS-System. Für jeden Feature-Branch entsteht eine isolierte Testinstanz. Die Abhängigkeit vom Operations-Team entfällt.
- Automatisierte Tests: Für jede ERP-Code-Änderung wird automatisch eine komplette Test-Umgebung mit ERP-VM, WMS-VM und simulierten Datenbanken hochgefahren.
Das Ergebnis: Deployment-Frequenz steigt von monatlich auf wöchentlich. Lead Time sinkt um 75%. Change Failure Rate halbiert sich. Ein kritischer Sicherheitspatch kann innerhalb von Stunden deployed werden – früher dauerte dies eine Woche.
Strategische Vorteile
- Erhöhte Agilität: Auch Legacy-Anwendungen werden schnell geändert und deployed. Neue Features werden häufiger ausgeliefert, Bugs schneller behoben.
- Reduzierte Komplexität: Einheitliche Tools und Prozesse vereinfachen die IT-Landschaft. Schulungsaufwand reduziert sich, Wissenstransfer wird erleichtert.
- Verbesserte Qualität: Automatisierte Tests fangen Fehler früher ab. Dies reduziert Produktionsausfälle und senkt Kosten für Fehlerbehebungen.
- Kosteneffizienz: Self-Service und Automatisierung reduzieren manuelle Intervention. Ressourcen werden besser genutzt, Gesamtbetriebskosten sinken.
- Complianceaspekte: Infrastructure as Code und GitOps schaffen vollständige Transparenz. Audit-Trails sind automatisch verfügbar, Rollback-Fähigkeiten minimieren Risiken.
Der Weg zur DevOps-Integration
- Phase 1 – Assessment: Bestandsaufnahme der VM-Landschaft. Identifizierung von Quick Wins – unkritische Systeme oder Entwicklungsumgebungen für erste Experimente. Bewertung der Team-Bereitschaft.
- Phase 2 – Pilotprojekt: Überschaubares Pilotprojekt für erste DevOps-Integration. Implementierung von Infrastructure as Code. Aufbau einer ersten CI/CD-Pipeline. Sammlung von Learnings und Best Practices.
- Phase 3 – Skalierung: Definition von Standards und Templates. Schrittweise Erweiterung auf weitere Systeme. Implementierung von Self-Service-Fähigkeiten. Kontinuierlicher Aufbau von Team-Expertise.
- Phase 4 – Reifegradsteigerung: Kontinuierliche Optimierung mit Metriken wie Deployment-Frequenz, Lead Time, Change Failure Rate. Erweiterung auf komplexere Szenarien und fortgeschrittene Praktiken wie Canary-Deployments.
Die Zukunft: DevOps als Standard
Die Zukunft der IT-Infrastruktur kennt keine Trennung mehr zwischen „traditionell“ und „modern“, zwischen VMs und Containern. DevOps-Praktiken werden zum Standard für alle Workload-Typen.
Red Hat OpenShift Virtualization ermöglicht Unternehmen, die Vorteile moderner DevOps-Praktiken auch für bestehende VM-Workloads zu nutzen, ohne diese grundlegend umbauen zu müssen. Dies beschleunigt die digitale Transformation und macht sie praktikabel – auch für Organisationen mit großem Legacy-Anteil.
Unternehmen, die heute diesen Weg beschreiten, etablieren eine Kultur der Agilität, Automatisierung und kontinuierlichen Verbesserung, die zum Wettbewerbsvorteil wird.
Ihr Weg zur DevOps-Plattform
Als Red Hat Premier Partner unterstützt die bitbone AG Sie dabei, OpenShift als umfassende DevOps-Plattform zu etablieren. Kontaktieren Sie uns für ein unverbindliches Gespräch zu OpenShift als DevOps-Plattform.