Die Umgebung: Eine Vier-Tier-Architektur an zwei Standorten
Vor der Migration betrieb das Team von Software Projects eine einheitliche, klar definierte Architektur in zwei IBM-Cloud-Regionen, ausgelegt auf Ausfallsicherheit: ein größerer Primärstandort und ein kleinerer Sekundärstandort. Beide Standorte folgten demselben Vier-Tier-Muster:
- Load Balancing: eine kleine Flotte von HAProxy-Instanzen, die Produktions-, Entwicklungs- und Tracking-Traffic getrennt voneinander bedient.
- Applikation: Web- und Tracking-Server, ein Runner für geplante Jobs, ein Server für Codequalität (SonarQube) und ein VPN-Gateway (nur am Primärstandort).
- Container-Orchestrierung: selbst verwaltete Docker-Swarm-Cluster – am Primärstandort als getrennte Produktions- und Entwicklungscluster, am Sekundärstandort als ein einzelnes Cluster.
- Daten: ein MySQL-Primary/Replica-Paar sowie ein Cassandra-Cluster mit drei Knoten, repliziert an beiden Standorten.
Der Migrationsplan von DoiT sah einen originalgetreuen 1:1-Lift-and-Shift dieser Topologie in eine einzige AWS VPC in us-east-1 vor – mit denselben Footprints von 24 und 16 Knoten, aber verteilt über mehrere Availability Zones innerhalb einer AWS-Region statt über zwei unabhängige, geografisch getrennte IBM-Cloud-Regionen. Die folgende Tabelle zeigt, wie die Zusammensetzung Tier für Tier unverändert übernommen wurde:
|
| Load Balancing (HAProxy) | 5 | 5 |
| Applikation und Tooling (Web, Tracking, geplante Jobs, Codequalität, VPN-Gateway) | 6 | 2 |
| Container-Orchestrierung (Docker Swarm – Produktions- + Entwicklungscluster) | 8 | 4 |
| Daten (MySQL Primary/Replica + Cassandra-Cluster mit 3 Knoten) | 5 | 5 |
| Knoten gesamt | 24 | 16 |
Diese Zahlen blieben auf beiden Seiten des Cutovers konstant – dieselben 24 und 16 Knoten, in denselben Proportionen pro Tier, lediglich verlagert. Diese Disziplin zahlte sich aus: Software Projects übernahm auf AWS eine Umgebung, die sich exakt so verhielt wie die, die das Team bereits kannte – während DoiT nebenbei eine Ebene an Infrastrukturkomplexität entfernte, indem zwei Rechenzentrumsregionen zu einer einzigen AWS-Region über mehrere Availability Zones konsolidiert wurden. Zugleich war damit die Modernize-Phase sauber vorbereitet, denn die Roadmap sah ohnehin vor, die selbst verwalteten Docker-Swarm-Cluster durch eine verwaltete Container-Plattform abzulösen, sobald die Umgebung auf AWS stabil lief.
Der Ansatz: AWS MAP, durchgängig umgesetzt
DoiT führte das Engagement über die drei AWS-MAP-Phasen hinweg – jede Phase legte das technische und finanzielle Fundament für die nächste, durchgängig umgesetzt vom Forward Deployment Engineering Team von DoiT.
|
| Fokus | Kostenmodellierung und Migrationsreife | Cloud-übergreifende Konnektivität und Cutover | Containerisierung und kontinuierliches FinOps |
| Status | Abgeschlossen | Abgeschlossen | In Arbeit |
1. Assess: Ein belastbares Migrationsbudget aufbauen
Bevor auch nur ein Workload bewegt wurde, benötigte das Team von Software Projects einen klaren Blick pro Service darauf, was Storage und Compute auf AWS kosten würden. DoiT erstellte eine detaillierte Kostenaufschlüsselung für EBS und EFS – mit Modellierung der monatlichen Kosten für Storage, IOPS und Durchsatz über Volume-Typen und Storage-Klassen hinweg –, damit Software Projects die kurz- und mittelfristigen Ausgaben für seine Migrations-Roadmap prognostizieren konnte. Außerdem arbeitete DoiT die Rabattstrategie für die Datenbank-Compute von Software Projects durch: DoiT Flexsave (ein rabattiertes Äquivalent zu Compute Savings Plans ohne Vorab-Commitment) im Vergleich zu Standard- und Convertible-Reserved-Instance-Preisen – inklusive der Trade-offs jeder Option mit Blick auf einen möglichen späteren Wechsel zu einem verwalteten Datenbankservice.
2. Mobilize: Cloud-übergreifende Konnektivität lösen
Die Konnektivität zwischen IBM Cloud und AWS war der kritische Pfad der gesamten Migration – und es gab dafür keine Standardlösung. DoiT führte eine strukturierte Bewertung der Optionen durch – AWS Direct Connect, eine dedizierte IBM-Direct-Link-Leitung, virtuelle Router-Appliances und ein leichtgewichtiges Mesh-VPN – und wog für jede Option Kosten, Stabilität und Einrichtungsaufwand ab:
- Evaluiert: AWS Direct Connect und IBM Direct Link Dedicated (einschließlich BGP-, IP-Range- und Abrechnungsrestriktionen) als Option für eine dedizierte Leitung.
- Pilotiert: ein Mesh-VPN-Overlay als schneller, kostenfreier Fallback, während längerfristige Optionen geprüft wurden.
- Begleitet: Software Projects beim Deployment und Tuning einer virtuellen Router-Appliance auf IBM-Seite, inklusive VLAN-Routing-Verhalten und Layer-2-Troubleshooting gemeinsam mit dem IBM-Support.
- Unterstützt: Software Projects beim Wechsel von IBM Classic Infrastructure zu IBM VPC für flexibleres Networking; anschließend Aufbau eines IPSec-Site-to-Site-VPN zwischen IBM VPC und einer AWS VPC.
- Diagnostiziert und behoben: eine Subnetz-Überschneidung und Routing-Lücke zwischen IBM Classic und AWS – durch Zuweisung eines dedizierten, überschneidungsfreien IP-Bereichs und Anpassung statischer Routen. Dieser Fix machte endlich bidirektionalen Traffic zwischen allen drei Umgebungen möglich.
Das Ergebnis war ein stabiler, verifizierter privater Netzwerkpfad zwischen IBM Classic Infrastructure, IBM VPC und AWS – das Fundament, auf dem das Team von Software Projects Workloads im eigenen Tempo verschieben konnte, ohne die Verbindung zu den noch auf IBM laufenden Systemen zu verlieren.
Stabile Produktion während der gesamten Transition
Während des Migrationszeitfensters leistete DoiT zudem schnellen operativen Support auf AWS-Seite. In einem Fall verlor eine EC2-Instanz unerwartet die SSM-Konnektivität – ohne verfügbaren SSH-Fallback. DoiT identifizierte die Ursache per Konsolen-Output-Diagnose: Das Root-Volume war vollgelaufen, wodurch der SSM-Agent nicht mehr starten konnte. Das Team lieferte einen Schritt-für-Schritt-Plan zur Behebung (Volume-Erweiterung und Filesystem-Resize) sowie proaktive CloudWatch-Alarme zur Disk-Auslastung und SNS-Benachrichtigungen, um eine Wiederholung zu verhindern – mit besonderem Augenmerk darauf, Produktionssysteme vor demselben Fehlermuster zu schützen.
3. Modernize: Container und kontinuierliche Kostenoptimierung
Nach Abschluss der Migration ging das Engagement in die Modernize-Phase über. Die Produktions- und Entwicklungs-Stacks von Software Projects liefen weiterhin auf selbst verwalteten Docker-Swarm-Clustern – funktional, aber mit dem operativen Aufwand manuell gepatchter Manager und Worker. DoiT unterstützt das Team von Software Projects nun dabei, diese Swarm-Cluster zugunsten einer verwalteten Container-Plattform auf AWS (Amazon EKS) abzulösen – direkt aufbauend auf dem konsolidierten Multi-AZ-VPC-Fundament aus der Mobilize-Phase, statt die Architektur von Grund auf neu zu entwerfen.
Im Zuge derselben Modernisierung sorgt DoiT dafür, dass die Cloud-Ausgaben diszipliniert bleiben, während sich die Umgebung weiterentwickelt. Mithilfe von DCI Insights prüfte DoiT die AWS-Detective- und GuardDuty-Konfiguration von Software Projects und stellte fest, dass die Kosten für Security-Tooling auf einen erheblichen Anteil der Gesamtausgaben angewachsen waren – vor allem getrieben durch die Ingestion großer Mengen an Flow-Logs, nicht durch tatsächlich gelieferten Sicherheitsmehrwert. DoiT quantifizierte die Trade-offs – einschließlich der Frage, welche hochkritischen Finding-Typen von welchen Datenquellen abhängen – und gab Software Projects eine klare, evidenzbasierte Auswahl an Optionen für das Right-Sizing der Security-Abdeckung, ohne die wertvollsten Detektionen zu verlieren. Derselbe disziplinierte, evidenzbasierte Ansatz setzt sich in der Containerisierung fort: von Anfang an passend dimensioniert statt nachträglich optimiert.
Die Lösung: Powered by DoiT Cloud Intelligence (DCI)
Neben der Hands-on-Umsetzung nutzte Software Projects während des gesamten Engagements mehrere Funktionen von DoiT Cloud Intelligence (DCI) – ein erfahrenes Delivery-Team kombiniert mit Self-Service-Transparenz über die eigene AWS-Umgebung:

|
| Forward Deployment Engineering | Das Hands-on-Team von DoiT, das die Assess-, Mobilize- und Modernize-Arbeit durchgängig umsetzte – von Netzwerkdesign und Cutover bis zur laufenden Optimierung |
| DCI Insights | Lieferte Empfehlungen zur Kostenoptimierung, darunter die in der Modernize-Phase genutzten Right-Sizing-Optionen für AWS Detective und GuardDuty |
| DCI Cloud Diagrams | Erfasste und visualisierte die AWS-Infrastruktur – dieselbe Vier-Tier-Topologie an zwei Standorten, die im Architekturvergleich weiter oben in dieser Case Study gezeigt wird |
| DCI Datadog Insights | Wird vom Kunden nun laufend genutzt, um die Observability- und Monitoring-Ausgaben im Blick zu behalten, während die Umgebung wächst |
| DCI AWS Intelligence | Wird vom Kunden nun laufend genutzt, um die gesamten AWS-Ausgaben in der konsolidierten Umgebung zu verfolgen |
Die letzten beiden Funktionen sind im Tagesgeschäft aktiv: Während das Team von Software Projects auf Container modernisiert, geben DCI AWS Intelligence und DCI Datadog Insights kontinuierliche Transparenz über die gesamten Cloud- und Observability-Ausgaben – statt zu warten, bis die Monatsrechnung ein Problem offenlegt.