Into Cloud 2.0
Weiterentwicklung einer bestehenden Cloud-Infrastruktur: Containerisierung weiterer Dienste, Einfuehrung von Infrastructure as Code und Ausbau der Automatisierung fuer schnellere Bereitstellungszyklen.
2018
Projektjahr
Enterprise
Branche
Docker / K8s
Plattform
DevOps
Rolle
Ausgangslage
Nach einer ersten Cloud-Migration, die grundlegende Dienste in eine Cloud-Infrastruktur überführt hatte, stand nun die zweite Phase an. Weitere Anwendungen und Dienste sollten containerisiert und in die bestehende Cloud-Plattform migriert werden. Die Erfahrungen aus der ersten Phase hatten gezeigt, dass nicht alle Anwendungen ohne Anpassung in eine Container-Umgebung überführt werden konnten.
Ziel von „Into Cloud 2.0″ war die systematische Containerisierung weiterer Dienste, die Weiterentwicklung der CI/CD-Pipelines und die Optimierung der bestehenden Cloud-Infrastruktur auf Basis der Erkenntnisse aus der ersten Phase.
Herausforderung & Ansatz
Herausforderung
- Legacy-Anwendungen, die nicht für Container-Betrieb ausgelegt waren
- Abhängigkeiten zwischen bereits migrierten und noch klassisch betriebenen Diensten
- Weiterentwicklung der CI/CD-Pipelines für heterogene Anwendungen
- Sicherstellung der Betriebsstabilität während der Migration
Ansatz
- Cloud-Readiness-Assessment für jede Anwendung
- Refactoring kritischer Legacy-Komponenten vor der Migration
- Erweiterung der CI/CD-Pipelines um Multi-Stage-Builds
- Blue-Green-Deployments für risikoarme Umstellungen
Umsetzung
Cloud-Readiness-Assessment
Jede Anwendung wurde anhand eines definierten Kriterienkatalogs bewertet: Stateless-Fähigkeit, externe Abhängigkeiten, Konfigurierbarkeit über Umgebungsvariablen, Log-Verhalten und Health-Check-Mechanismen. Auf Basis der Bewertung wurde entschieden, ob eine Anwendung direkt containerisiert, vorher refaktorisiert oder als Ausnahme weiterhin klassisch betrieben werden sollte.
Containerisierung und CI/CD
Die Containerisierung folgte einem standardisierten Prozess: Erstellung eines Dockerfiles mit Multi-Stage-Build, Definition der Kubernetes-Manifeste (Deployment, Service, Ingress, ConfigMap) und Integration in die CI/CD-Pipeline. Die Pipelines wurden um automatisierte Security-Scans der Container-Images, Integrationstests und Performance-Tests erweitert.
Migration und Cutover
Die Migration einzelner Dienste erfolgte über Blue-Green-Deployments. Beide Versionen liefen parallel, bis die neue Container-Version alle Akzeptanztests bestanden hatte. Der Traffic wurde dann schrittweise umgeleitet, zuerst für interne Nutzer, dann für einen Prozentsatz des produktiven Traffics und schließlich für alle Nutzer. Ein automatischer Rollback-Mechanismus stellte sicher, dass bei Problemen sofort auf die alte Version zurückgewechselt werden konnte.
Kenntnisse
Cloud & Container
- Docker
- Kubernetes
- Multi-Stage-Builds
CI/CD
- GitLab CI/CD
- Blue-Green-Deployment
- Security-Scans
Ergebnis & Fazit
Ergebnis
- Weitere Dienste erfolgreich in die Cloud-Plattform migriert
- Erweiterte CI/CD-Pipelines mit Security-Scans und Integrationstests
- Risikoarme Migration durch Blue-Green-Deployments
- Standardisierter Cloud-Readiness-Bewertungsprozess
Fazit
Die zweite Phase einer Cloud-Migration ist oft anspruchsvoller als die erste, weil die einfach zu migrierenden Dienste bereits überführt sind. Die systematische Bewertung der Cloud-Readiness, das gezielte Refactoring kritischer Komponenten und die risikoarme Migration über Blue-Green-Deployments ermöglichten eine erfolgreiche Fortsetzung der Cloud-Strategie ohne Beeinträchtigung des laufenden Betriebs.
